La implantación de un GMAO es donde se decide si el proyecto rinde o fracasa. El producto puede ser excelente — Fracttal, FMINCI, Infraspeak, Mapex, da igual — pero si la implantación se hace mal, el equipo termina rechazando el sistema en 3-6 meses y la empresa vuelve a Excel disimuladamente. Lo dice la propia industria: las referencias públicas indican que entre el 40% y el 60% de implantaciones GMAO no llegan al año en plena operación.

Este artículo explica las 10 fases reales de una implantación bien hecha. Basado en proyectos que hemos ejecutado nosotros (IDOM, ingeniería multi-sede, completado en 6-10 semanas) y en patrones públicos del sector. No es teoría — es lo que pasa de verdad cuando se hace bien.

Por qué la implantación es lo que más fracasa en proyectos GMAO

La gente piensa que un GMAO falla por la tecnología. Casi nunca. Falla por la implantación. Y la implantación falla por razones que no son técnicas.

Primero, decisiones operativas no resueltas. La implantación exige decidir docenas de cosas: cómo se nombran los activos, qué tipos de incidencia existen, quién aprueba qué, qué permisos tiene cada rol, cómo se categoriza el preventivo. Si el cliente no tiene esas decisiones tomadas, el proyecto se queda en cola esperando consenso. El proveedor no puede avanzar si tú no decides.

Segundo, disponibilidad real del equipo cliente. El proveedor pone su PM, su equipo de configuración y su soporte. Pero necesita interlocutores en el cliente con tiempo bloqueado. Si el responsable de mantenimiento ya tiene su jornada llena y la implantación es “lo que se pueda entre llamadas”, el proyecto no avanza. Es la causa silenciosa número uno de retrasos.

Tercero, resistencia al cambio del equipo. Cambiar un sistema que la gente lleva 5 años usando (aunque sea Excel) genera fricción. El técnico que apunta en su libreta y luego vuelca al WhatsApp del jefe no quiere abrir una app nueva. Si nadie gestiona la resistencia explícitamente — con formación, comunicación, ejemplo — el sistema se queda sin usar.

Cuarto, querer replicar el sistema antiguo en el nuevo. Si tu Excel tenía mala estructura, replicarla en el GMAO te deja con el mismo problema. La implantación es la oportunidad única para rediseñar nomenclatura, jerarquía y procesos. Si no se aprovecha ahora, no se aprovecha nunca.

Estos cuatro problemas son los que las metodologías serias de implantación atacan en cada fase.

Las 10 fases reales (no las que vende cualquier consultora)

Estas son las 10 fases de una implantación bien hecha. Cada fase tiene un objetivo claro, entregables verificables y un riesgo principal a mitigar.

Fase 1: kick-off y alineación (semana 1)

Reunión inicial entre el proveedor y el cliente. Objetivo: validar alcance, plazos, responsables y metodología. Se confirman las 3-5 prioridades del proyecto (qué problemas queremos resolver primero), se asignan roles (sponsor, product owner cliente, PM proveedor, responsable de mantenimiento, técnicos senior), se acuerdan reuniones recurrentes (semanal de seguimiento, quincenal de validación).

Entregable: acta de kick-off firmada con alcance, plazos y responsables.

Riesgo principal: que el sponsor ejecutivo no esté presente o no se comprometa con disponibilidad real. Si el sponsor no aparece en el kick-off, el proyecto tiene un techo de prioridad bajo desde el día 1.

Fase 2: auditoría de la operación actual (semanas 1-2)

El equipo del proveedor analiza cómo trabajas hoy: qué herramientas usas, qué datos tienes, qué procesos sigues, qué problemas concretos quieres resolver. Entrevistas con responsable, técnicos senior y administración. Revisión del Excel actual u otro sistema.

Entregable: documento de auditoría con diagnóstico, listado de procesos, propuesta de cambios y plan de migración de datos.

Riesgo principal: que la auditoría se quede en superficie. Si solo se mira lo que el responsable cuenta y no se pasea por las sedes ni se habla con los técnicos, el diseño posterior va a fallar en campo.

Fase 3: diseño de procesos y arquitectura del sistema (semanas 2-3)

Decisiones clave sobre cómo va a funcionar el GMAO en tu operación. Jerarquía de activos (empresa > sede > zona > sistema > equipo > componente), tipos de incidencia (correctivo, preventivo, mejora, inspección), niveles de prioridad y SLA asociados, perfiles de usuario y permisos, flujos de aprobación si los hay, integraciones necesarias.

Entregable: documento de diseño funcional revisado y aprobado por el cliente.

Riesgo principal: replicar el sistema antiguo sin cuestionarlo. La implantación es el momento para limpiar — si vienes de Excel con mala nomenclatura de activos, no la repitas en el GMAO.

Fase 4: configuración del sistema (semanas 3-4)

El proveedor configura el GMAO según el diseño aprobado. Esta fase es ejecución técnica — el cliente revisa al final, no participa activamente. Carga de catálogos maestros (activos, proveedores, repuestos, tipos), configuración de workflows, definición de plantillas de preventivo, ajustes de notificaciones y alertas, configuración de roles y permisos.

Entregable: sistema configurado en entorno de pre-producción, listo para revisión del cliente.

Riesgo principal: que la configuración se haga sin validación intermedia. Si el cliente solo revisa al final, los desajustes se acumulan y los ajustes son más costosos.

Fase 5: migración de datos históricos (semana 4)

Carga de datos del sistema antiguo al GMAO: activos, historial de mantenimiento relevante (12-24 meses, no 8 años), preventivos abiertos, stock de repuestos, base de proveedores. La regla pragmática: migrar lo que realmente se consulta y archivar el resto en un Excel de referencia.

Entregable: datos históricos cargados, validados por muestreo (10-20% de registros).

Riesgo principal: migrar datos sucios. Si el Excel original tiene duplicados, nomenclatura inconsistente o datos obsoletos, hay que limpiar antes de migrar. Limpiar después es 5x más costoso.

Fase 6: integraciones técnicas (semanas 4-5, paralelo)

Si hay integraciones con ERP, contabilidad, herramientas de comunicación u otros sistemas, se ejecutan en paralelo a la fase de configuración y migración. Típico: webhook para crear incidencias desde formulario externo, conector con contabilidad para volcar gastos, integración con Microsoft Teams o WhatsApp para notificaciones.

Entregable: integraciones funcionando en entorno de pruebas, con casos de éxito y de error documentados.

Riesgo principal: subestimar la complejidad de las integraciones con sistemas legacy del cliente. Si el ERP del cliente no tiene API pública, la integración puede ser un proyecto entero por sí mismo.

Fase 7: formación del equipo (semana 5)

Formación estructurada por perfil. Responsable de mantenimiento (4 horas, gestión de catálogos, reporting, supervisión). Administrativo si lo hay (2 horas, gestión de incidencias y proveedores). Técnicos en campo (1-2 horas, solo lo que van a usar: abrir, cerrar, comentar órdenes desde el móvil). Sponsor (1 hora ejecutiva, KPIs y dashboard).

Entregable: equipo formado con material de consulta posterior (vídeos, manual o cheat sheet).

Riesgo principal: formar a los técnicos en aula. Los técnicos aprenden por uso, no por escucha. La formación debe ser corta y enfocada en sus 5 acciones diarias.

Fase 8: piloto controlado (semana 5-6)

Antes del go-live total, una parte de la operación se traslada al GMAO en paralelo al sistema antiguo. Típico: una sede, un tipo de incidencia, un equipo. Durante 5-7 días laborables, esa parte usa exclusivamente el GMAO y el resto sigue en el sistema antiguo. Se identifican fricciones, ajustes finales y mejoras de configuración.

Entregable: lista de incidencias del piloto resueltas, ajustes aplicados, confirmación de readiness para go-live.

Riesgo principal: saltarse el piloto por presión de plazo. El piloto detecta el 80% de los problemas reales antes del go-live. Saltárselo es jugarse semanas de retrabajo.

Fase 9: go-live (día D, semana 6 típica)

Corte del sistema antiguo para nuevas incidencias. Todo lo nuevo entra al GMAO. Idealmente lunes a primera hora, después de fin de semana de validación final. Proveedor disponible toda la jornada. Comunicación clara al equipo: el sistema oficial es ahora el GMAO, Excel queda como archivo de consulta histórica.

Entregable: GMAO operativo como sistema único para nuevos registros.

Riesgo principal: que aparezcan incidencias críticas y nadie del proveedor esté disponible en el momento. El proveedor tiene que estar presente — física o remotamente — durante todo el primer día.

Fase 10: estabilización y revisión a 30 días (semanas 6-10)

Las primeras 4 semanas post go-live son las más críticas. El proveedor mantiene soporte intensivo (respuesta en horas), ajusta configuración según uso real, refuerza al equipo donde la adopción baja. A los 30 días hay una revisión formal: qué ha funcionado, qué no, qué ajustes hacen falta a 3 meses.

Entregable: informe de adopción a 30 días con KPIs (incidencias creadas en GMAO vs canales paralelos, tiempo medio de cierre, % cumplimiento preventivo, satisfacción del equipo).

Riesgo principal: que el proveedor se desconecte tras el go-live. Si el soporte intensivo cae bruscamente, la adopción se hunde con él. La regla: soporte cercano durante 4-6 semanas, no solo el día del go-live.

Plazos típicos: 6-10 semanas vs 6-9 meses, ¿cuál es real?

Hay un debate constante en el sector sobre plazos. Algunos proveedores prometen implantación en 2 semanas. Otros estructuran proyectos de 6-9 meses. ¿Cuál es real?

Ambos lo son, en contextos diferentes.

Implantaciones de 4-6 semanas: empresas pequeñas o medianas con una sola sede, operativa estable, datos limpios, sin integraciones complejas. El producto se configura, los datos se migran (volumen pequeño), el equipo se forma, hay un piloto de pocos días, go-live. Encaja bien con mid-market español ICP-FMINCI.

Implantaciones de 6-10 semanas: empresas mid-market con 2-5 sedes, una o dos integraciones, datos a limpiar. El plazo de referencia de IDOM (ingeniería multi-sede) entra en este rango — completaron go-live en este plazo. Esto es lo que FMINCI publica como referencia operativa.

Implantaciones de 3-6 meses: empresas grandes con varias entidades legales, multi-sede internacional, integraciones con ERP enterprise (SAP, Oracle), workflows complejos. Típico de Fracttal, IBM Maximo y SAP PM para mid-market grande.

Implantaciones de 6-12 meses: corporativos con operación en varios países, multi-divisa, integraciones críticas con sistemas legacy, alto requerimiento de personalización. Típico de SAP PM enterprise, IBM Maximo enterprise, Fracttal enterprise.

Las cifras inferiores (2 semanas) suelen indicar producto plug-and-play sin configuración seria. Las cifras superiores sin razón clara suelen indicar sobre-ingeniería. La pregunta correcta al proveedor: “para una empresa como la mía, ¿en cuánto tiempo nos vamos a go-live, y por qué ese plazo?”. Si la respuesta es coherente con el tamaño y la complejidad, el plazo es real.

Roles necesarios en tu equipo durante el proyecto

Los proyectos GMAO no se ejecutan solo desde el proveedor. El cliente necesita asignar y bloquear tiempo a los siguientes perfiles.

Sponsor ejecutivo (1-2 horas al mes). Quien valida decisiones estratégicas y desbloquea recursos. Suele ser director de operaciones, director de mantenimiento o director general en empresas pequeñas. No participa en el día a día, pero está en el kick-off, en la validación del diseño y en la revisión a 30 días.

Product owner interno (5-10 horas a la semana). La persona que decide operativamente por el cliente. Habla con el proveedor, traslada feedback del equipo, valida configuración, asiste a reuniones de seguimiento. Es el rol más crítico — sin product owner, el proyecto se atasca. Suele ser el responsable de mantenimiento o un coordinador asignado.

Responsable de mantenimiento (3-5 horas a la semana). Quien conoce la operación al detalle: qué activos, qué procesos, qué casos especiales. Si no es la misma persona que el product owner, son los dos roles que más trabajan en el proyecto. Aprueba la jerarquía de activos, los workflows y la configuración funcional.

Técnicos senior (2 horas a la semana, fases 7-10). 1-2 técnicos de campo que prueban la app móvil, trasladan feedback de campo, participan en el piloto. Son la voz del usuario final. Si la app no funciona para ellos, el sistema fracasa en operación.

Responsable IT (2-4 horas en fases 4-6). Si hay integraciones, gestión de usuarios o configuración de red, IT entra en estas fases. No es un rol full-time durante el proyecto, pero su intervención en momentos clave es necesaria.

Administración / contabilidad (2 horas en fase 6 si hay integración). Si el GMAO se integra con contabilidad para volcar gastos o facturas, una persona de administración participa en la fase de integración.

Sin estos roles asignados y con tiempo bloqueado en agenda, el proyecto se retrasa. No por culpa del proveedor — por culpa de la falta de capacidad del cliente. Esta es la causa silenciosa número uno de retrasos en proyectos GMAO.

Lo que tu proveedor debería hacer (y muchos no hacen)

No todos los proveedores ejecutan implantaciones del mismo modo. Algunos venden producto y dejan al cliente solo. Otros tienen metodología y acompañamiento real. La diferencia entre uno y otro es la diferencia entre éxito y fracaso del proyecto.

Tu proveedor debería hacer todo esto. Si alguno falla, ya tienes señal.

Auditar tu operación antes de configurar. No empezar a montar el sistema sin haber entendido cómo trabajas hoy. Si el comercial te vende implantación en 2 semanas sin haber visto tu Excel, mal asunto.

Asignar un PM dedicado al proyecto. Una persona con nombre y apellido, que conoce tu proyecto, que asiste a las reuniones semanales, que conoces tú por nombre. No “el equipo de implantación” genérico.

Pasear por tus sedes si la operación lo justifica. Si tienes operación presencial en varias sedes, el proveedor debe visitar al menos una. Sin ver el campo, el diseño se hace en abstracto.

Limpiar tus datos contigo, no migrar lo sucio. El proveedor debe ayudarte a identificar duplicados, errores de nomenclatura y datos obsoletos antes de migrar. Si te dicen “migramos lo que nos pases”, te van a dejar con tus mismos problemas en el nuevo sistema.

Formar de forma diferenciada por rol. No la misma formación de 6 horas para todos. Cada perfil necesita lo suyo: responsables formación completa, técnicos formación corta y enfocada.

Hacer piloto controlado antes del go-live. No saltárselo aunque haya prisa. El piloto detecta problemas reales que la configuración en frío no detecta.

Estar presente el día del go-live. Física o remotamente, pero presente durante toda la jornada. No “te llamo si tienes problemas”.

Soporte intensivo las primeras 4 semanas. Respuesta en horas, no en días. Si el proveedor desaparece tras el go-live, la adopción se hunde.

Revisión formal a 30 días. Con KPIs reales, no con percepciones. Es la única forma de saber si el proyecto va bien o necesita correcciones.

Hablar claro sobre lo que el producto no hace. Si hay funcionalidades que tú necesitas y el producto no tiene, el proveedor debe decirlo en la fase de auditoría, no descubrirlo en la fase 8.

El día del go-live: cómo prepararse

El go-live es el momento simbólico más importante del proyecto. Aunque técnicamente sea solo “encender el sistema”, lo que pase ese día define la percepción del equipo durante las siguientes semanas.

Prepararlo en viernes anterior. Revisión final de configuración, validación de datos, confirmación de readiness del proveedor. Si algo falla, se aborta el go-live y se reagenda. Mejor reagendar 1 semana que ir a un go-live con problemas conocidos.

Comunicación clara al equipo el viernes. “El lunes a las 9:00 todo nuevo entra al GMAO. Excel queda solo para consulta histórica.” Sin ambigüedades. Email + reunión presencial corta.

Lunes 9:00 — go-live. Soporte del proveedor presente (física o remoto). Responsable de mantenimiento disponible toda la jornada para resolver dudas. Técnicos senior testeando la app desde primera hora.

Resolver incidencias en el momento, no acumular. Si aparece un fallo, se resuelve esa hora, no se anota para el viernes. Cada hora de retraso multiplica la resistencia del equipo.

Cierre del día con reunión de 30 minutos. Qué ha pasado, qué ha funcionado, qué no, qué ajustes hay que hacer mañana. Sin reunión de cierre, los problemas se diluyen.

Las primeras 4 semanas tras go-live: estabilización

El go-live no es el final del proyecto. Es el principio de la fase más crítica: la estabilización. Lo que pase aquí define si el sistema se queda o se abandona.

Semana 1 post go-live. Soporte del proveedor con respuesta en horas. Ajustes diarios de configuración según uso real. Refuerzo presencial al equipo si la adopción baja. Reunión de seguimiento diaria al final del día (15 minutos).

Semana 2. Frecuencia de soporte sigue alta. Empiezan a aparecer los primeros patrones: qué funcionalidades se usan, cuáles no, dónde hay fricción. Ajustes de configuración basados en datos reales, no en hipótesis.

Semana 3. Soporte se reduce gradualmente. El equipo opera con autonomía creciente. Aparecen primeras incidencias que el equipo resuelve sin proveedor. Reuniones de seguimiento cada 2 días.

Semana 4. Revisión formal de 30 días. KPIs: % incidencias creadas en GMAO vs canales paralelos, tiempo medio de cierre comparado con sistema anterior, % cumplimiento preventivo, satisfacción del equipo (encuesta corta). Si los KPIs están en target, el proyecto se considera estabilizado. Si no, se diseñan acciones correctivas a 60 días.

A partir del mes 2, soporte estándar según contrato. El proyecto ha cerrado. Empieza la operación normal.

Errores que disparan el plazo (y cómo evitarlos)

Por experiencia y patrones públicos del sector, los 5 errores que más alargan los plazos son los siguientes.

1. Falta de product owner interno. Sin alguien que decida operativamente por el cliente, todas las decisiones se atascan en cola. Mitigación: asignar product owner desde la fase 1, con tiempo bloqueado en agenda.

2. Datos históricos sucios sin limpiar. Migrar Excel con duplicados, nomenclatura inconsistente y datos obsoletos te deja con los mismos problemas. Mitigación: invertir 1-2 semanas en limpieza previa antes de migrar.

3. Querer personalizar todo en la primera versión. Pedir 15 personalizaciones específicas en la implantación inicial alarga el proyecto y diluye el foco. Mitigación: implantar con configuración estándar primero, personalizar después del go-live según necesidad real.

4. Saltarse el piloto. “Vamos directos a go-live, total ya está todo configurado”. Mal cálculo. El piloto detecta el 80% de problemas reales. Mitigación: no negociar el piloto.

5. Falta de comunicación con el equipo. El equipo se entera del cambio el día del go-live. Resistencia inmediata. Mitigación: comunicar desde la fase 1, explicar por qué cambiamos, dar voz al equipo en el diseño.

Evitando estos cinco, los proyectos se mantienen en plazo. No es magia — es metodología.

Lecturas relacionadas