Un ERP mal implantado no se nota el día del arranque: se nota seis meses después, cuando el equipo mantiene una hoja de cálculo paralela porque el sistema “no sirve para lo nuestro”. A esas alturas ya se ha pagado la licencia, la consultoría y la migración, y volver atrás cuesta más que seguir.
Casi todos los proyectos que descarrilan lo hacen por las mismas razones, y ninguna es técnica. Estos son los diez fallos que más se repiten y cómo se detectan a tiempo.
En corto: las implantaciones de ERP rara vez fracasan por el software. Fracasan por alcance mal definido, datos de origen sucios, exceso de personalización, ausencia de un responsable interno con capacidad de decidir y formación dejada para el final. Son problemas de gestión, y todos son evitables.
1. Empezar sin haber mapeado los procesos
Es el error de origen del que salen casi todos los demás. Se compra el ERP y después se descubre cómo trabaja realmente la empresa, normalmente en mitad de la configuración.
El proceso documentado y el proceso real casi nunca coinciden. La persona de administración lleva ocho años aplicando una excepción que no está escrita en ninguna parte y que resulta ser el 30% de los pedidos.
Cómo evitarlo: dedica las primeras semanas a documentar el flujo real —no el del manual— de pedido a cobro y de compra a pago. Siéntate con quien lo ejecuta a diario, no solo con quien lo dirige. Ese mapa es el que después permite decidir con criterio qué se estandariza y qué se respeta.
2. Definir el alcance como una lista de deseos
Cuando se pregunta a cada departamento qué necesita, salen doscientos requisitos y todos son “imprescindibles”. El resultado es un proyecto que no cabe en el presupuesto y que se recorta a mitad de camino, casi siempre por donde más duele.
Cómo evitarlo: clasifica cada requisito en tres cajas: bloquea la operación, ahorra tiempo medible y estaría bien. La primera caja entra en la fase 1, la segunda se prioriza por horas ahorradas al mes, y la tercera se revisa seis meses después del arranque. Muchos de esos requisitos se caen solos al ver el sistema funcionando.
3. Migrar datos sucios
Es la causa número uno de retrasos, y la más subestimada. Nadie quiere reconocer que el maestro de clientes tiene duplicados, referencias obsoletas y campos rellenados a mano con criterios distintos según el año.
Un ERP no arregla eso: lo hereda y lo amplifica, porque ahora ese dato alimenta contabilidad, almacén y facturación a la vez.
Cómo evitarlo: audita los datos antes de firmar el calendario. Cuenta duplicados, huecos y valores fuera de rango en clientes, artículos y proveedores. Limpia en origen y aprovecha para archivar lo que ya no se usa: migrar quince años de histórico que nadie consulta encarece el proyecto sin aportar nada. Nuestra guía sobre migrar de Excel a un ERP entra en el detalle de esta fase.
4. Personalizar todo desde el primer día
La personalización es adictiva porque siempre parece razonable en la reunión. El problema aparece en la primera actualización del producto, cuando hay que revisar cada desarrollo a medida uno por uno.
Cada personalización se paga tres veces: al construirla, al mantenerla y en cada actualización.
Cómo evitarlo: aplica la regla de partida de adaptar el proceso al estándar, y personalizar solo cuando ese proceso sea una ventaja competitiva real. Si tu forma de calcular escandallos es lo que te distingue, personalízala. Si es el formato del albarán, adáptate. Una prueba útil: pregunta qué pasaría si ese proceso se hiciera como lo hace el resto del sector. Si la respuesta es “nada grave”, no lo personalices.
5. No poner un responsable interno con poder de decisión
El proyecto necesita a alguien de casa que decida cuando dos departamentos discrepan sobre cómo debe funcionar un flujo. Si esa figura no existe, cada decisión escala a dirección y el calendario se llena de esperas.
El fallo asociado es igual de frecuente: nombrar a esa persona y no descargarle de trabajo. Un proyecto de ERP consume tiempo real, y quien lo lidera con su jornada ya completa acaba atendiendo lo urgente y aplazando lo importante.
Cómo evitarlo: nombra un responsable con autoridad sobre procesos y asígnale un porcentaje explícito de su jornada. Que esté escrito, no sobreentendido.
6. Dejar la formación para el final
Es el recorte fácil cuando el presupuesto aprieta: se reduce la formación a una sesión de dos horas la semana anterior al arranque. Después el equipo aprende sobre la marcha, cada uno a su manera, y se consolidan formas erróneas de usar el sistema que luego cuesta mucho corregir.
Cómo evitarlo: forma por rol y no por módulo —a cada persona lo que va a usar—, hazlo con datos reales de la empresa y programa una segunda sesión dos o tres semanas después del arranque, que es cuando aparecen las preguntas de verdad. Reserva ese presupuesto desde el principio y protégelo.
7. Elegir el arranque big bang sin necesidad
Arrancar todos los módulos y todas las sedes el mismo día es tentador porque parece más limpio. También significa que cualquier problema aparece a la vez en todos los frentes y con toda la empresa mirando.
Cómo evitarlo: en organizaciones pequeñas con procesos homogéneos, el big bang es asumible. En estructuras multiempresa, multipaís o con fabricación, arranca por fases: un módulo o una sede primero, se estabiliza, y se replica lo aprendido. Alarga el calendario y reduce muchísimo el riesgo.
8. Confundir el go-live con el final del proyecto
El día del arranque el sistema funciona, pero la organización todavía no. Las primeras semanas concentran incidencias, dudas y ajustes, y es justo cuando el equipo de implantación suele desmovilizarse.
Cómo evitarlo: planifica una fase de estabilización con soporte reforzado y un canal único donde el equipo pueda preguntar sin fricción. Mide incidencias por semana: si no bajan, algo del diseño no encaja con la operación real y conviene revisarlo antes de que se normalice el uso de atajos.
9. No integrar el ERP con lo que ya funciona
Un ERP que no habla con la tienda online, el CRM o el TPV convierte a alguien del equipo en un puente humano que copia datos de un sistema a otro. Ese trabajo no aparece en ningún presupuesto y sin embargo se paga todos los meses.
Cómo evitarlo: identifica desde el principio los puntos de contacto entre sistemas y trátalos como parte del alcance, no como un extra. Comprueba que el ERP tenga API documentada y verifica que las integraciones que te prometen existan ya, funcionando en un cliente real. Nosotros hemos hecho este trabajo tanto sobre producto estándar —por ejemplo integrando Odoo— como construyendo la capa a medida cuando el estándar no llegaba.
10. Medir el éxito por el cumplimiento del calendario
Entregar en plazo un sistema que nadie usa no es un éxito. Sin embargo el calendario es lo único que muchos comités miden, porque es lo más fácil de mirar.
Cómo evitarlo: define dos o tres indicadores de negocio antes de empezar y mídelos a los tres y a los seis meses. Por ejemplo: días de cierre contable, tiempo desde pedido hasta albarán, porcentaje de pedidos con incidencia. Si el ERP funciona, esos números se mueven. Si no se mueven, tienes un problema aunque el proyecto se entregara puntual.
Señales de alerta durante el proyecto
Cuatro síntomas que anticipan problemas con semanas de antelación:
| Señal | Lo que suele indicar |
|---|---|
| Las reuniones de seguimiento se vacían | La organización ha dejado de sentir el proyecto como suyo |
| Aparecen hojas de cálculo paralelas en pruebas | El sistema no cubre un flujo real y nadie lo ha dicho |
| Todas las decisiones escalan a dirección | Falta un responsable con poder real |
| La lista de personalizaciones crece cada semana | El alcance no se cerró de verdad |
Cómo lo planteamos nosotros
En Soamee empezamos siempre por el mapa de procesos y por la auditoría de datos, antes de hablar de módulos. Y decimos que no cuando lo que el cliente necesita es un producto estándar bien configurado en lugar de un desarrollo: si tu operación encaja en lo que ya existe en el mercado, la comparativa entre Odoo, SAP y Sage para pymes es mejor punto de partida que cualquier propuesta nuestra.
El desarrollo a medida tiene sentido cuando el proceso que te diferencia no cabe en el producto estándar, y la señal es concreta: horas de personal dedicadas cada mes a cuadrar a mano lo que el sistema no sabe hacer. Cuando ese coste supera al de construirlo bien, la decisión ya está tomada.
¿Tienes una implantación en marcha que no acaba de arrancar, o estás a punto de empezar una? Cuéntanos el caso y te damos una lectura honesta de por dónde se está torciendo.