¿Por qué fallan tantas implantaciones de GMAO?

Por una combinación de tres factores que aparecen en casi todos los casos. Primero: el cliente no asigna product owner interno con tiempo bloqueado. Las decisiones se atascan en cola y el proyecto se alarga. Segundo: se intenta replicar el sistema antiguo en el nuevo sin aprovechar la migración para limpiar. Tercero: el proveedor desaparece tras el go-live y la adopción se hunde sin soporte cercano. Los tres son evitables con metodología, pero los tres son comunes porque la presión de plazo y la falta de experiencia previa los enmascaran hasta que ya es tarde.

¿De quién es la culpa cuando una implantación fracasa?

Casi siempre es compartida. El proveedor tiene responsabilidad sobre la metodología, la disponibilidad de su equipo, la formación y el soporte cercano. El cliente tiene responsabilidad sobre las decisiones operativas, la disponibilidad de su equipo, la limpieza de datos y el seguimiento de adopción. Atribuir el fracaso solo a una parte suele indicar mala lectura de causa. Lo útil es identificar qué se hizo mal en cada lado y cómo evitar repetirlo en el siguiente intento.

¿Cuándo se sabe que una implantación va mal?

Hay tres señales tempranas. Primera: en la fase de auditoría, el proveedor no hace preguntas operativas y va directo a configurar. Segunda: el cliente no asigna product owner o le bloquea solo 2 horas a la semana. Tercera: la fase de diseño se cierra sin que el responsable de mantenimiento haya revisado en detalle la jerarquía de activos y los workflows. Si ocurren las tres, el proyecto va a tener problemas garantizados. Si ocurre alguna, ya hay riesgo. Lo correcto es parar, hacer auditoría del proyecto y corregir antes de seguir.

¿Se puede recuperar una implantación que ha empezado mal?

Sí, pero no es fácil. La recuperación exige reconocer el problema, parar el proyecto, revisar lo hecho y replanificar. Típicamente se hace un reset parcial: se mantiene la configuración correcta, se rehacen las decisiones equivocadas, se forma de nuevo donde haga falta y se relanza con metodología más estricta. El coste de recuperar es mayor que el de hacer bien desde el principio — entre 1.5x y 3x el plazo original típicamente. Por eso es tan importante detectar los errores en las primeras 2-3 semanas, no esperar a que sean evidentes en la semana 8.

¿Qué diferencia hay entre un proveedor serio y uno que no lo es?

Un proveedor serio te audita la operación antes de configurar, asigna PM dedicado con nombre y apellido, te dice claramente qué no hace su producto, hace piloto antes de go-live y mantiene soporte intensivo las primeras 4 semanas. Un proveedor no serio te vende producto, configura sin auditoría, promete que su producto lo hace todo, salta el piloto por presión comercial y desaparece tras go-live. La diferencia se nota en la primera reunión comercial. Si el comercial pregunta cómo trabajas tú, ya tienes señal positiva. Si solo habla de su producto, mala señal.

Los 12 errores más caros en la implantación de un GMAO (y cómo evitarlos)

Por Mario Ferrer Marín · Publicado el 13 de mayo de 2026 · 10 min de lectura

Si estás pensando en implantar un GMAO o ya estás en mitad del proyecto, este artículo te interesa. Los errores que aparecen aquí no son hipotéticos — son los que se repiten en proyecto tras proyecto, en cliente tras cliente, en sector tras sector. Saberlos de antemano no garantiza evitarlos, pero no saberlos casi garantiza cometerlos.

Hay dos tipos de errores en una implantación GMAO: los del cliente y los del proveedor. Los responsables son distintos pero el impacto es el mismo — plazos disparados, adopción baja, equipo desmotivado, posible fracaso del proyecto. Esta lista ataca los 6 más caros de cada lado.

Por qué fallan las implantaciones GMAO

Las referencias públicas del sector indican que entre el 40% y el 60% de implantaciones de GMAO no llegan al año con el sistema en plena operación. La cifra es alta pero coherente con lo que se ve en campo: muchas empresas vuelven a Excel disimuladamente al cabo de 6-9 meses, dejando el GMAO como herramienta a medio gas.

Las razones suelen ser tres, en distintas combinaciones. Primero, decisiones operativas mal tomadas en fase de diseño que arrastran el proyecto. Segundo, falta de disponibilidad real del equipo cliente — tiempo no bloqueado, product owner inexistente, sponsor ausente. Tercero, ausencia de metodología del proveedor en post go-live, con soporte que se desinfla en cuanto el contrato está firmado.

Los errores que verás más abajo son consecuencias concretas de estos tres problemas. Identificarlos a tiempo es lo que separa proyectos exitosos de fracasos.

Errores del cliente

Error 1: no asignar product owner interno con tiempo bloqueado

Es el error más frecuente y el más caro. El cliente firma contrato, el proveedor empieza, y nadie por parte del cliente tiene tiempo real bloqueado para liderar el proyecto. El responsable de mantenimiento sigue con su jornada llena, el director tiene reuniones, y las decisiones del proveedor se quedan en cola esperando respuesta. Las semanas pasan, el proyecto no avanza, y la frustración crece en ambos lados.

Cómo evitarlo. En la fase de kick-off, asignar product owner explícitamente con nombre y apellido. Bloquearle entre 5 y 10 horas semanales en agenda durante toda la duración del proyecto. Si nadie puede asumir ese rol, plantearse posponer el proyecto hasta que sea viable.

Error 2: querer replicar el sistema antiguo en el GMAO

El Excel actual tiene 15 hojas, nomenclatura inconsistente y procesos heredados de hace 5 años. En lugar de aprovechar la implantación para rediseñar, el cliente pide al proveedor que “configure como está ahora, que el equipo no se confunda”. Resultado: el GMAO replica los mismos problemas en otra herramienta, con coste añadido.

Cómo evitarlo. En la fase de diseño, cuestionar cada decisión heredada. ¿Por qué se nombra así? ¿Por qué se gestiona así? ¿Qué ganamos manteniendo esta estructura? Si la respuesta es “porque siempre se ha hecho así”, es candidata a rediseñar. La implantación es la oportunidad única para limpiar.

Error 3: no liberar tiempo a los técnicos en campo

Los técnicos siguen con sus rutas, sus incidencias urgentes y sus llamadas. La formación del GMAO se mete con calzador al final de la jornada, cansados, sin atención. La prueba del piloto se hace mientras siguen con su carga habitual, sin tiempo real para probar. Resultado: la app móvil llega al go-live mal probada y el equipo la rechaza por fricción en campo.

Cómo evitarlo. Asumir que la implantación exige liberar 2-3 horas semanales a técnicos senior durante las fases 7-10. Si no se puede liberar, el proyecto se retrasa, no se acelera. Es un coste que el cliente debe asumir, no esperar que el proveedor lo compense con magia.

Error 4: comunicación al equipo solo en el go-live

El equipo se entera del cambio el día del go-live, sin contexto previo. Reacción natural: resistencia, miedo a perder control, sensación de que les imponen una herramienta sin haberles preguntado. La adopción en las primeras semanas se hunde por razones emocionales, no técnicas.

Cómo evitarlo. Comunicar desde la fase 1: por qué cambiamos, qué vamos a ganar, cómo va a cambiar el día a día. Reuniones cortas (15 minutos) cada 2-3 semanas con el equipo. Dar voz al equipo en el diseño (recoger feedback en fase de auditoría). La adopción se construye desde semanas antes, no el día del corte.

Error 5: pedir personalización antes de validar el estándar

Cliente que en fase de diseño pide 12 personalizaciones específicas — campos nuevos, workflows custom, integraciones a medida, dashboards exclusivos. El proyecto se alarga 6-8 semanas adicionales y el alcance se dispara. Al final, la mitad de las personalizaciones no se usan porque el equipo se acostumbra al estándar.

Cómo evitarlo. Implantar con configuración estándar primero (la que el GMAO trae de fábrica con ajustes mínimos). Identificar después del go-live, con uso real durante 3-4 meses, qué personalizaciones son necesarias de verdad. Pedirlas entonces, con justificación basada en datos. La mayoría de personalizaciones pedidas en fase de diseño se descartan luego.

Error 6: presionar para reducir plazos sin reducir alcance

Cliente que firma con un plazo de 8 semanas y a las 2 semanas pide reducir a 5 “porque hay un evento importante en la empresa”. El proveedor no puede hacer en 5 semanas lo que requiere 8 sin saltarse fases críticas — típicamente el piloto y la formación en campo. Resultado: go-live forzado, problemas en campo, adopción mala.

Cómo evitarlo. Si el plazo se reduce, reducir el alcance proporcionalmente. Por ejemplo: implantar en una sola sede primero y desplegar al resto en fases posteriores. Mantener todas las fases pero con scope menor. Saltarse fases nunca sale gratis.

Errores del proveedor

Error 7: configurar sin auditar la operación real

Comercial que cierra contrato y pasa el proyecto a su equipo de implantación con “ya tenemos el Excel, configurad lo estándar”. Sin entender qué activos hay, qué procesos sigue el cliente, qué casos especiales tiene, qué normativa aplica. El sistema se monta en abstracto y en la fase 8 (piloto) aparecen 30 ajustes obvios que se podrían haber detectado en la auditoría.

Cómo evitarlo desde el cliente. Exigir auditoría seria en la fase 1-2. Entrevistas con responsable y técnicos. Visita presencial a una sede si la operación es presencial. Documento de auditoría escrito antes de empezar a configurar. Si el proveedor no lo hace, ya tienes señal.

Error 8: no asignar PM dedicado

Proveedor que pone “el equipo de implantación” genérico en lugar de un PM con nombre y apellido. Cada reunión la lleva una persona distinta, las decisiones se pierden entre interlocutores, el cliente tiene que repetir contexto cada vez. El proyecto pierde continuidad y velocidad.

Cómo evitarlo desde el cliente. Pedir PM dedicado por escrito antes de firmar. Que asista a kick-off y a todas las reuniones semanales. Que sea el único punto de contacto principal — si hay especialistas técnicos en momentos puntuales, vale, pero el hilo lo lleva el PM.

Error 9: prometer lo que el producto no hace

Comercial que en fase de venta dice “sí, claro” a todas las preguntas para cerrar el contrato. En fase de implantación aparece que dos de las funcionalidades prometidas no existen o son desarrollos a medida con coste adicional. Cliente se siente engañado, proyecto entra en crisis de confianza.

Cómo evitarlo desde el cliente. En la demo, hacer preguntas concretas con casos reales. Pedir que el comercial diga qué no hace su producto. Si responde a todo “sí claro”, desconfía. Antes de firmar, pedir por escrito que las funcionalidades críticas están incluidas en el plan contratado, no son desarrollos extra.

Error 10: saltarse el piloto por presión comercial

Proveedor con varios proyectos en paralelo que comprime la fase de piloto a 1-2 días o la salta directamente. Va a go-live sin haber probado con datos reales del cliente. Resultado: en la primera semana aparecen fallos que se podrían haber detectado en el piloto, la adopción se hunde, hay que parar el sistema y reconfigurarlo a posteriori.

Cómo evitarlo desde el cliente. No negociar el piloto. Aunque haya presión de plazo, exigir 5-7 días laborables de piloto antes del go-live. Si el proveedor se niega, mala señal. El piloto detecta el 80% de problemas reales — saltarlo es jugarse semanas de retrabajo.

Error 11: desaparecer tras el go-live

El proveedor pone soporte intensivo el día del go-live y la primera semana, y a partir de ahí se desconecta. El cliente se queda solo con un sistema recién implantado, equipo en aprendizaje, dudas operativas constantes, sin respuesta del proveedor en horas o días laborables. La adopción cae en picado en las semanas 2-4.

Cómo evitarlo desde el cliente. Negociar por escrito soporte intensivo durante las primeras 4 semanas tras go-live. Reuniones de seguimiento cada 2-3 días en la primera semana, semanales en las semanas 2-4. SLA reforzado en este periodo. Si el proveedor se niega, replantear la firma.

Error 12: no hacer revisión formal a 30 días

El proveedor da el proyecto por cerrado en cuanto se hace el go-live y firma el acta de entrega. No hay revisión formal a 30 días con KPIs reales. El cliente queda con la sensación de que el proyecto ha terminado, pero la adopción no está consolidada. A los 3 meses, se descubre que el equipo no usa el 30% de las funcionalidades y nadie ha intervenido para corregirlo.

Cómo evitarlo desde el cliente. Pactar por escrito una revisión formal a 30 días post go-live con KPIs medidos (% incidencias en GMAO vs canales paralelos, tiempo medio de cierre, % cumplimiento preventivo, satisfacción del equipo). Si los KPIs están por debajo, plan correctivo a 60 días. Solo entonces se considera el proyecto cerrado.

Cómo prevenir cada uno desde la firma del contrato

Los 12 errores se previenen mayoritariamente con cláusulas y compromisos escritos en el contrato. Algunos elementos que deberían aparecer.

Por parte del cliente, antes de firmar. Compromiso explícito de asignar product owner con horas bloqueadas en agenda. Disponibilidad de responsable de mantenimiento (3-5h/semana) y técnicos senior (2h/semana) durante el proyecto. Plan de comunicación interna al equipo desde el inicio.

Por parte del proveedor, antes de firmar. Asignación de PM dedicado con nombre y apellido. Metodología de implantación con las 10 fases descritas en el artículo de implantación paso a paso. Auditoría de la operación antes de empezar a configurar. Piloto controlado de 5-7 días antes del go-live. Soporte intensivo durante las 4 primeras semanas tras go-live. Revisión formal a 30 días con KPIs.

Cláusulas operativas en el contrato. SLA de soporte por escrito con tiempos por nivel. Penalización si el proveedor no entrega en plazo por causas atribuibles a él. Penalización si el cliente no aporta disponibilidad acordada. Procedimiento de escalado si hay desviaciones (sponsor de ambas partes).

Sin estos compromisos por escrito, los errores son inevitables en algún grado. Con ellos, no están eliminados, pero están controlados. Y eso es lo que separa un proyecto que llega al éxito de uno que se queda a medio camino.