Desarrollo de CMMS en 2026: comprar, construir e implantar

El desarrollo de un CMMS consiste en construir un software de mantenimiento que mantenga un registro único y fiable de tus activos, del trabajo hecho sobre ellos y del trabajo que vence a continuación. En 2026 la decisión rara vez es "comprar o construir" en abstracto: herramientas de mercado como Fiix, Limble o MaintainX cubren bien las plantas estándar, mientras que un CMMS a medida gana cuando tienes tipos de activo poco habituales, cuadrillas de campo offline, integración profunda con ERP o IoT, o muchas plantas donde el precio por usuario deja de tener sentido. Elijas la ruta que elijas, la implantación (censo de activos, criticidad, migración de planes de preventivo, piloto, despliegue) decide si el sistema se usa o no.

Qué gestiona realmente un CMMS

Un CMMS es el sistema de registro del mantenimiento. Gestiona ocho cosas.

Activos y jerarquía. Cada equipo recibe un identificador único y un lugar en un árbol: planta, área, línea, máquina, componente. La jerarquía importa porque costes, fallos y planes de preventivo se consolidan a través de ella.

Órdenes de trabajo. La unidad de trabajo. Una orden tiene tipo (correctivo, preventivo, inspección, proyecto), prioridad, técnico o cuadrilla asignada, mano de obra planificada y real, repuestos consumidos y un estado que va de la solicitud al cierre.

Planes de mantenimiento preventivo. Reglas que generan órdenes de trabajo automáticamente: cada 90 días, cada 500 horas de funcionamiento, cada 10.000 ciclos o cuando se cumple una condición. Un plan agrupa lista de tareas, duración estimada, repuestos necesarios y pasos de seguridad.

Inspecciones y checklists. Formularios estructurados vinculados a una orden de trabajo o a una ruta: lecturas, ítems apto/no apto, fotos, firmas. Las inspecciones alimentan tanto los registros de cumplimiento como los disparadores por condición.

Inventario de repuestos. Niveles de stock por almacén, puntos de pedido mín/máx, repuestos vinculados a los activos en los que encajan y reservas contra trabajo planificado. Si ya operas un sistema de almacén, consulta nuestra guía sobre desarrollo de un sistema de gestión de inventario para ver dónde debe estar la frontera.

Técnicos y programación. Habilidades, certificaciones, turnos, disponibilidad y un tablero de planificación que convierte el backlog en una programación semanal.

Ejecución móvil y offline. Los técnicos reciben el trabajo, escanean etiquetas de activos, completan checklists, adjuntan fotos y cierran órdenes desde un teléfono o tablet, con o sin cobertura.

KPIs. Los que importan:

KPI	Qué te dice	Uso típico
MTBF (tiempo medio entre fallos)	Fiabilidad de un activo o clase	Priorizar rediseño o sustitución
MTTR (tiempo medio de reparación)	Velocidad de restablecimiento	Detectar cuellos de botella de habilidades, repuestos o acceso
Cumplimiento del preventivo	Proporción de órdenes preventivas completadas a tiempo	Salud del programa preventivo
Proporción planificado vs. reactivo	Cuánto trabajo es programado vs. emergencia	Madurez de la función de mantenimiento
Antigüedad del backlog	Cuánto espera el trabajo abierto	Planificación de capacidad
Roturas de stock en trabajo planificado	Repuestos que faltan al empezar un trabajo	Ajuste del inventario

CMMS vs EAM vs APM

	CMMS	EAM	APM
Foco	Ejecución del mantenimiento	Ciclo de vida y finanzas del activo	Fiabilidad y predicción
Objetos centrales	Activos, órdenes de trabajo, planes de preventivo, repuestos	Más compras, contratos, depreciación, baja	Más datos de condición, modelos de fallo, puntuaciones de riesgo
Propietario típico	Responsable de mantenimiento	Finanzas y operaciones	Ingeniería de fiabilidad
Entradas de datos	Técnicos, planificadores	ERP, compras	Sensores IoT, SCADA, historians
Ejemplos	Fiix, Limble, MaintainX, UpKeep	IBM Maximo, SAP PM (S/4HANA Asset Management)	GE Vernova APM, AVEVA, add-ons APM de Maximo

Regla práctica: empieza con alcance de CMMS. Añade capacidades de EAM cuando finanzas necesite que el registro de activos cuadre con el inmovilizado, y añade APM cuando tengas suficientes datos de sensores e historial de fallos para que un modelo supere al calendario.

Comprar o construir: CMMS de mercado o CMMS a medida

Fiix, UpKeep, Limble y MaintainX son productos SaaS mobile-first que una planta pequeña puede poner en marcha en semanas. IBM Maximo y SAP PM son plataformas corporativas que presuponen un integrador de sistemas y un programa de varios años. El CMMS a medida es la tercera opción.

Criterio	CMMS SaaS (Fiix, UpKeep, Limble, MaintainX)	EAM corporativo (Maximo, SAP PM)	CMMS a medida
Tiempo hasta la primera orden de trabajo	Días a semanas	Meses	Dos a cuatro meses para un MVP
Encaje con activos poco habituales (activos lineales, flotas, equipos de laboratorio, material de alquiler)	Modelo de activo genérico; apaños con campos personalizados	Fuerte, pero con mucha configuración	Modelado exactamente como lo ve tu negocio
Móvil offline	Parcial; varía por proveedor y plataforma	Módulos adicionales, a menudo con licencia aparte	Offline-first por diseño si lo especificas
Integración con ERP, IoT, SCADA	APIs REST y conectores; límites de profundidad y volumen	Profunda, a coste del integrador	Nativa; los contratos son tuyos
Modelo de precios	Por usuario al mes; se dispara con muchos técnicos	Por usuario o por planta, más licencias y consultoría	Coste de desarrollo inicial; coste marginal casi nulo por usuario o planta
Propiedad y exportación de datos	Exportables, pero el esquema y el historial viven en el proveedor	Tuyos, on-prem o en la nube, pero atados a la plataforma	Totalmente tuyos
Actualizaciones	Automáticas, a veces disruptivas	Proyectos mayores	Tu roadmap, tu presupuesto
Ideal para	Una o pocas plantas, equipos estándar	Sectores regulados e intensivos en capital	Muchas plantas, activos especializados, operaciones con mucha integración

Dos señales empujan hacia lo a medida. La primera es aritmética: si tienes 200 técnicos en 15 plantas, el precio por usuario del SaaS a cinco años suele superar el coste de construir y operar tu propio sistema, y aun así no eres dueño del modelo de datos. La segunda es el encaje: cuando tu "activo" es un kilómetro de tubería, una flota de vehículos que se mueve entre plantas o una unidad de alquiler que cambia de cliente cada semana, un árbol genérico de activos te pelea cada día.

Dos señales empujan hacia la compra. Si tu proceso de mantenimiento es estándar y tu equipo tiene menos de 30 personas, una herramienta SaaS será más barata y más rápida. Y si el CMMS debe superar auditorías regulatorias estrictas (farmacéutica, aviación), las plataformas validadas traen una documentación que de otro modo tendrías que escribir tú.

Arquitectura de un CMMS a medida

Cinco partes concentran la mayor parte del riesgo de diseño.

Modelo de activos

Modela la jerarquía como un árbol con nodos tipados. Cada tipo de activo declara sus propios atributos (un motor tiene kW y RPM; un vehículo tiene odómetro y matrícula) y sus propios contadores. Mantén una jerarquía separada de location: los activos se mueven, las ubicaciones no. Da a cada activo un identificador público estable impreso en su etiqueta, distinto de la clave de base de datos, para que un reetiquetado nunca rompa el historial.

Máquina de estados de la orden de trabajo

Define los estados explícitamente y aplica las transiciones en el código:

requested -> approved -> planned -> scheduled -> in_progress
in_progress -> on_hold (esperando repuestos / acceso / permiso) -> in_progress
in_progress -> completed -> closed
any -> cancelled (con motivo)

Cada transición registra quién, cuándo y por qué. Ese log es lo que permite calcular después el MTTR y la antigüedad del backlog. No dejes que cada planta defina sus propios estados; permite subestados dentro de on_hold.

Motor de programación del preventivo

El motor se ejecuta de forma programada y responde a una pregunta por plan: ¿necesita existir una orden de trabajo ahora? Soporta tres tipos de disparador desde el principio: calendario (intervalo fijo o fecha fija), contador (horas de funcionamiento, ciclos, kilómetros, con lecturas manuales o de sensores) y condición (un umbral sobre un valor monitorizado). Dos reglas evitan la mayoría de los bugs en producción: nunca generes una nueva orden preventiva mientras la anterior siga abierta, y calcula el siguiente vencimiento desde la finalización, no desde la fecha original, salvo que el plan sea explícitamente de "calendario fijo".

Sincronización móvil offline-first

La app móvil debe tener una copia local del trabajo del técnico: órdenes asignadas, sus activos, checklists, repuestos e historial reciente. Las escrituras ocurren en local y se sincronizan cuando hay conexión. Diseña los conflictos explícitamente: un supervisor reasignando una orden mientras el técnico la completa offline es un evento diario, no un caso límite. Last-write-wins es aceptable para notas de texto libre; las transiciones de estado necesitan validación en el servidor, con una ruta clara de "esta orden cambió en el servidor" dentro de la app. Usa un outbox para las subidas (las fotos son la parte pesada) y mantén un log de sincronización legible. Nuestra comparativa de desarrollo móvil cubre los trade-offs de framework para este tipo de app.

IoT y monitorización de condición

Los sensores y PLCs producen lecturas; el CMMS no debería almacenarlas todas. Pon un stream o un historian entre ambos, evalúa allí umbrales y tendencias, y envía al CMMS solo actualizaciones de contador y eventos de condición. El CMMS convierte entonces un evento en una orden de trabajo a través del mismo motor de preventivo. El lado de la ingesta, protocolos como OPC UA y MQTT y el procesamiento en el edge se tratan en nuestra guía de desarrollo de aplicaciones IoT para la Industria 4.0; el patrón para desacoplar los dos sistemas es el descrito en arquitectura basada en eventos.

Integración con el ERP

La división limpia: el CMMS es dueño de la ejecución del mantenimiento; el ERP es dueño del dinero y de las compras. En concreto:

• Activos: el inmovilizado del ERP y el árbol de activos del CMMS comparten un identificador, pero no son la misma lista. El árbol del CMMS es mucho más granular. Sincroniza el vínculo, no la estructura.
• Repuestos: elige un único maestro. Si el ERP lleva las compras, el CMMS lee niveles de stock y escribe consumos; los pedidos de reposición salen del ERP.
• Costes: las órdenes completadas imputan mano de obra y repuestos a centros de coste en el ERP, normalmente en un batch nocturno.
• Solicitudes de compra: una orden a la espera de un repuesto genera una solicitud en el ERP y recibe el estado de vuelta.

Prefiere eventos y APIs idempotentes antes que bases de datos compartidas y CSVs nocturnos. Cuando el propio ERP es a medida, las fronteras son más fáciles de negociar; nuestro artículo sobre desarrollo de sistemas ERP personalizados explica cómo mantener esos módulos separados.

Implantación de un CMMS: paso a paso

El software es la mitad pequeña de una implantación de CMMS; los datos y los hábitos son la mitad grande. Esta secuencia funciona igual para sistemas a medida y de mercado.

1. Censo de activos. Recorre la planta. Etiqueta cada activo que vaya a recibir una orden de trabajo, registra tipo, ubicación, fabricante, modelo y número de serie, y fotografía la placa de características. No importes la hoja de cálculo antigua tal cual; ahí viven los duplicados y los activos fantasma. Una planta con unos miles de activos lleva semanas, no días.

2. Clasificación por criticidad. Puntúa cada activo en seguridad, impacto en producción, coste de reparación y redundancia. Una clasificación simple A/B/C basta. La criticidad decide la profundidad del preventivo, el stock de repuestos y qué activos reciben sensores primero. Los activos de clase C funcionan hasta el fallo, sin checklist de 40 pasos.

3. Migración de planes de preventivo. Revisa cada plan existente contra el historial de fallos antes de migrarlo. Los planes que generan trabajo que nadie hace, o que nunca previnieron nada, se descartan o se fusionan. Estandariza las listas de tareas por clase de activo en lugar de por activo, y después vincúlalas.

4. Limpieza de repuestos y almacén. Cuenta el stock, retira repuestos obsoletos, vincula repuestos a activos y fija mín/máx en los repuestos de clase A. Si te lo saltas, los técnicos se saltarán el sistema la primera vez que un repuesto reservado no esté en la estantería.

5. Planta piloto. Elige una planta o un área con un supervisor comprometido, una mezcla representativa de activos y un tamaño manejable. Hazla funcionar de seis a doce semanas con órdenes reales. Arregla primero el flujo de trabajo, después el software.

6. Despliegue. Planta a planta, con el equipo del piloto formando a la siguiente. Congela la configuración entre oleadas; libera las solicitudes de cambio por oleada.

7. Métricas de adopción. Síguelas desde el primer día del piloto:

• Proporción de órdenes creadas desde el móvil vs. por los planificadores a posteriori
• Proporción de órdenes cerradas en las 24 horas siguientes a su finalización
• Cumplimiento del preventivo por planta
• Número de activos con cero órdenes tras 90 días (o están mal en el registro o no se mantienen)
• Proporción planificado vs. reactivo, mes a mes

Cuando estas métricas se estabilizan, la implantación ha terminado. Cuando caen, alguien volvió al papel.

Checklist de decisión

Elige un CMMS SaaS de mercado cuando:

• Tienes una o pocas plantas con equipos industriales o de instalaciones estándar
• Menos de unos 30 usuarios tocarán el sistema
• Tus integraciones se limitan a exportar informes y quizá sincronizar repuestos
• Necesitas estar en producción en semanas

Elige un EAM corporativo cuando:

• Finanzas exige que el registro de activos concilie con el inmovilizado
• Las auditorías regulatorias exigen una plataforma validada y documentada
• Ya operas SAP o IBM y la relación con el integrador existe

Elige un CMMS a medida cuando:

• Tus activos no encajan en un árbol genérico (lineales, móviles, alquiler, laboratorio, multi-tenant)
• Los técnicos trabajan sin conectividad y el offline es innegociable
• El CMMS debe hablar con ERP, SCADA, plataformas IoT o un portal de clientes en ambos sentidos
• El número de usuarios o plantas convierte el precio por puesto en la mayor partida del presupuesto de mantenimiento
• La propiedad de los datos y una capa de analítica propia son estratégicas, no un extra

Plan por fases

Fase	Duración (orden de magnitud)	Alcance	Criterio de salida
0. Discovery	3–6 semanas	Mapeo de procesos, plan del censo de activos, modelo de criticidad, decisión comprar vs. construir	Alcance y modelo de datos aprobados
1. Fundación	2–3 meses	Árbol de activos, ciclo de vida de la orden, motor de preventivo, móvil básico, almacén	La planta piloto puede ejecutar todo el trabajo diario en el sistema
2. Piloto	6–12 semanas	Una planta en producción, métricas de adopción, correcciones de flujo	Cumplimiento del preventivo y tasa de cierre móvil estables
3. Integración	2–3 meses, en paralelo al despliegue	Costes y repuestos del ERP, lecturas de contadores IoT, almacén de informes	La sync nocturna del ERP concilia; los eventos de condición crean órdenes
4. Despliegue	1–2 meses por oleada	Plantas restantes por oleadas, train-the-trainer	Todas las plantas en el sistema, papel retirado
5. Optimización	Continua	Ajuste de intervalos de preventivo con datos de MTBF, disparadores por condición, APM si se justifica	Proporción planificado vs. reactivo mejorando trimestre a trimestre

Recomendación

Operación estándar y pequeña: compra Limble, MaintainX, Fiix o UpKeep, dedica el esfuerzo al censo de activos y a la revisión de planes de preventivo, y vuelve a evaluar en tres años. Muchas plantas, activos especializados, cuadrillas offline o integración pesada: construye un CMMS a medida con un modelo de activos tipado, una máquina de estados explícita para las órdenes, un motor de preventivo con disparadores de calendario, contador y condición, y una app móvil offline-first. Costará menos a cinco años y los datos se quedan contigo. En cualquier caso, sigue la secuencia de implantación en orden; los proyectos que fracasan se saltan el censo y el piloto. En Arvucore solemos recomendar una fase de discovery que termine con la decisión comprar vs. construir sobre el papel, respaldada por el número de usuarios, los tipos de activo y la lista de integraciones, antes de que alguien escriba código o firme una suscripción.