Cómo implementar un CMMS: el caso de ANCAP con SAP-PM

En una línea

Implementar un CMMS no es instalar un software: en el caso de ANCAP, de 39 semanas de proyecto la mayor parte se fue en definir procesos y una matriz de riesgo objetiva, no en parametrizar pantallas.

El problema que buscaba resolver

ANCAP, la petrolera estatal uruguaya, mantenía su Refinería La Teja con siete unidades ejecutoras (seis talleres más Zonas Exteriores) que priorizaban, planificaban y programaban el mantenimiento cada una por su cuenta. Esa descentralización no tenía un criterio común: generaba desequilibrios grandes en el cumplimiento de las solicitudes de trabajo. El sistema existente (SIMAN, de una firma argentina) se sincronizaba solo mensualmente con los sistemas de materiales y costos, y la planificación y programación se hacían en Excel sobre el servidor de SIMAN — una tarea tediosa, con múltiples iteraciones cada vez que un plan involucraba varios talleres a la vez. Cuando se quiso llevar indicadores clave de desempeño (KPIs) de forma sistemática, el sistema existente no daba para eso, y ahí empezó la búsqueda de un CMMS.

La matriz de riesgo: priorizar sin depender de quién pide

Antes de tocar ningún software, la consultora que acompañó el proyecto (KBC Advanced Technologies) recomendó algo distinto: una "matriz de riesgo" que prioriza los trabajos según las consecuencias potenciales de no hacerlos y la probabilidad de que esas consecuencias ocurran en un plazo determinado. Es una herramienta objetiva que no depende de quién pide el trabajo ni de quién lo ejecuta.

El caso tiene, además, una lección honesta sobre el diseño de cualquier sistema de reglas: la matriz solo se aplicaba a las órdenes de trabajo, no a los "services" (intervenciones de hasta 8 horas-hombre, gestionadas en un módulo más ágil con menos registro). Algunos solicitantes "ingeniosos" empezaron a fraccionar trabajos grandes en varios services para esquivar la priorización — lo que terminó sobrecargando las cuadrillas de services, en perjuicio de las órdenes legítimamente priorizadas. Resolver ese bypass en el nuevo sistema fue, según el propio autor, uno de los puntos que más tiempo de análisis llevó del proyecto.

Las 5 fases del proyecto

Fase I — Selección y capacitación (3 semanas). Se armó un grupo de 5 usuarios referentes (2 gerentes y 3 jefes de departamento, dedicación part-time para decisiones estratégicas) y 8 usuarios funcionales con dedicación full-time. Se capacitó a 16 personas en los módulos de mantenimiento (PM) y materiales (MM) a la vez, por la fuerte interrelación entre ambos.

Fase II — Modelo conceptual (16 semanas, en promedio 10 personas full-time). Se formaron dos subgrupos: uno para análisis de procesos y otro para datos maestros. El de procesos identificó unos 20 procesos, de los cuales 4 eran los principales (otra vez la lógica de Pareto) y se atacaron primero. La premisa del proyecto era "cero desarrollo a medida": SAP se adaptaba a los procedimientos de ANCAP donde era posible, y ANCAP se adaptaba a SAP donde no. El entregable de esta fase fue un "Business Blueprint" que documentaba cada paso necesario para la parametrización posterior, siguiendo la metodología ASAP (Accelerated SAP).

Fase III — Parametrización, carga de datos y pruebas. Toda la parametrización se hizo en un ambiente de desarrollo separado de los datos reales, y luego se "transportó" a los ambientes de producción y de pruebas — un procedimiento pensado específicamente para minimizar errores de configuración. Se cargaron 22.507 ubicaciones técnicas y 12.766 equipos. En promedio trabajaron 14 personas en el módulo de mantenimiento durante esta fase, y cerca de 40 personas en el proyecto SAP completo (que incluía además abastecimiento, costos, activo fijo, finanzas y presupuesto).

Fase IV — Capacitación de usuarios y puesta en productivo. Se dictaron cursos durante 4 semanas a 140 usuarios. La puesta en productivo fue en la semana 39 del proyecto, con una transición de fin de semana descripta como "muy exigente" — el equipo decidió deliberadamente una transición rápida y contundente en vez de una migración gradual, con una mesa de ayuda telefónica y por correo más soporte de campo dedicado.

Fase V — Mejora continua. Se creó un "Centro de Competencia" (una programadora y un analista full-time, más dos usuarios clave parametrizadores) para sostener el sistema después del arranque — con reuniones cuya frecuencia bajó a medida que el módulo se estabilizó.

Aviso y Orden: la distinción que organiza todo

En la terminología de SAP, una solicitud de intervención genera primero un Aviso de mantenimiento, vinculado al historial del equipo y a los catálogos de mantenimiento; el aviso da origen después a una Orden, que es la que se vincula con costos y con recursos humanos (mano de obra, materiales, tarifas por puesto de trabajo). Hacen falta los dos documentos para gestionar el activo con eficiencia: uno sin el otro deja un historial incompleto o un control de costos sin trazabilidad hacia el porqué del gasto.

Ubicación técnica y Equipo: por qué no son lo mismo

SAP distingue la ubicación técnica (la función a cumplir, por ejemplo "bomba 2806") del equipo (quién cumple físicamente esa función en este momento). El caso documenta un ejemplo real: la ubicación técnica 2806-JA tenía montada una bomba marca Worthington, con una bomba Sulzer de respaldo disponible para la misma función. Si el equipo Worthington se cambia de ubicación en algún momento de su vida útil, su historial de mantenimiento lo sigue — no se queda pegado a la ubicación técnica donde estuvo instalado. Es la diferencia entre preguntar "¿qué le pasó a esta bomba (la máquina física)?" y "¿qué le pasó a esta función (la ubicación)?", y el sistema necesita responder ambas preguntas sin mezclarlas.

Resultados

El proyecto completo tomó 39 semanas (algo más de 9 meses), lo que el autor señala como coherente con las estadísticas propias de SAP para proyectos de esta envergadura (entre 7 y 9 meses). El equipo osciló entre 10 y 14 personas según la fase, con un total de 19.000 horas-hombre invertidas. Para la planificación de las paradas de planta (cada 4 años, con una intensidad de ejecución que se cuadruplica respecto al mantenimiento de rutina) se usó además un software específico de gestión de proyectos (Primavera P3), que permitió devolver la planta a Operaciones 2 días antes de lo tradicional — una mejora que, por sí sola, pagó la inversión en el software y en el equipo dedicado a planificar la parada.

La mejora general de gestión se verificó externamente: ANCAP participa desde 1996 en la encuesta de desempeño de refinerías de Solomon Associates, y esos indicadores reflejaron la mejora de costos y de disponibilidad mecánica de la planta.

Para qué sirve conocer este caso

Un CMMS no resuelve por sí solo un problema de gestión: ANCAP definió primero la matriz de riesgo y la planificación centralizada (fases que no dependían de ningún software), y solo después buscó una herramienta que pudiera sostener ese modelo con datos en tiempo real. Comprar el sistema antes de tener claro el proceso es, de hecho, la secuencia inversa a la que este caso documenta como exitosa.

Beneficios

• La matriz de riesgo da un criterio objetivo de priorización, independiente de quién solicita o ejecuta el trabajo
• La distinción entre ubicación técnica y equipo resuelve un problema real de trazabilidad: el historial de una máquina no se pierde cuando esa máquina cambia de función o de lugar
• Los números del caso (39 semanas, 19.000 HH, 140 usuarios capacitados) dan una referencia concreta de la magnitud real de un proyecto de este tipo, útil para dimensionar antes de arrancar uno propio

Limitaciones a tener en cuenta

• El caso describe una refinería grande (22.500 ubicaciones técnicas, cerca de 13.000 equipos) — la escala del proyecto no es representativa de una planta mediana o pequeña
• La premisa de "cero desarrollo a medida" exigió que la organización se adaptara a SAP en varios puntos, no solo al revés — una decisión de gestión que no todas las empresas están dispuestas a tomar
• Es el reporte de un proyecto exitoso contado por su propio responsable — no incluye una comparación con proyectos similares que hayan fracasado o se hayan retrasado

En resumen

ANCAP no empezó por el software: empezó por una matriz de riesgo objetiva y una planificación centralizada, y recién después implementó SAP-PM en 5 fases a lo largo de 39 semanas para sostener ese modelo con datos en tiempo real. El resultado — menos costo de mantenimiento, mejor disponibilidad, 2 días menos de parada de planta — se verificó con una encuesta externa de desempeño, no solo con la percepción interna de que "ahora el sistema es mejor".