Rescate de proyectos ERP
Tu ERP no sale a producción: cinco causas frecuentes
Cinco causas frecuentes por las que un proyecto de ERP no llega a producción: alcance, rotación del proveedor, datos sin migrar y falta de validación.
· 5 min de lectura
Hay proyectos de ERP que llevan meses sin fecha de salida y ninguno lo dice en voz alta. Se sigue hablando de configuración pendiente, de una prueba más, de un módulo que falta ajustar. Nadie dice la frase completa: este proyecto no está saliendo a producción.
No hay una sola causa. Pero después de ver varios proyectos atorados, las mismas cinco se repiten con distintos nombres de empresa. Y casi nunca aparecen solas: suelen venir combinadas, lo que hace más difícil que alguien dentro del proyecto vea el patrón completo mientras lo está viviendo.
El alcance que creció sin control
El proyecto arrancó con un alcance definido: tantos módulos, tantas empresas, tantas integraciones. A la tercera junta ya se sumó un reporte que no estaba, una regla de aprobación que alguien pidió, una integración con un sistema que nadie había mencionado.
Cada suma por separado parece razonable. Juntas, mueven la fecha de salida sin que nadie haya tomado esa decisión de forma explícita. El proyecto no se atrasó de golpe, se fue atrasando en incrementos que nadie sumó a tiempo.
El equipo del proveedor cambió a mitad de proyecto
El consultor que levantó los requerimientos ya no es el que está configurando el sistema. El nuevo equipo hereda documentación incompleta, decisiones que no quedaron por escrito y una curva de aprendizaje que se paga con el calendario del cliente.
Cuando esto pasa más de una vez en el mismo proyecto, el patrón se vuelve difícil de esconder: cada relevo de consultor añade semanas que no estaban en el plan original, y el cliente termina explicando su propio negocio por segunda o tercera vez a gente nueva.
Datos que nunca terminaron de migrarse bien
La migración de datos suele ser la parte menos visible del proyecto y la que más lo detiene. Catálogos de clientes duplicados, códigos de producto con tres versiones distintas, saldos históricos que nadie se atreve a conciliar porque nadie entiende de dónde salió la diferencia.
Salir a producción con datos así no resuelve el problema, lo traslada a un sistema nuevo y más caro. Por eso muchos proyectos se frenan justo antes del corte final: alguien, con razón, se niega a firmar el paso a producción con esos números.
El punto ciego frecuente es que la limpieza de datos casi nunca se le asigna a alguien con tiempo dedicado. Se reparte entre las mismas personas que ya están operando el día a día, y ese trabajo, que no es pequeño, avanza a la velocidad de lo que sobra entre una tarea urgente y otra.
Nadie en la empresa valida antes de salir en vivo
El proveedor prueba el sistema contra los requerimientos que levantó. Pero el requerimiento y la operación real no siempre coinciden, y la única forma de encontrar esa diferencia es que alguien del negocio pruebe el sistema haciendo su trabajo real, no un caso de prueba genérico.
Cuando esa validación no pasa por el área que va a usar el sistema todos los días, el proyecto puede parecer terminado en la demo y fallar en la primera semana real de operación.
Esto se agrava cuando el sistema tiene más de un dueño interno. Si finanzas pidió el proyecto pero operaciones es quien lo va a usar todos los días, y operaciones nunca se sentó a validar porque nadie la convocó formalmente, cualquier hallazgo tardío se descubre después de la salida en vivo, cuando corregirlo cuesta más y presiona más al equipo.
La curva que todo proyecto atraviesa, y cuándo deja de ser normal
Todo proceso de cambio hunde el rendimiento de la operación antes de recuperarlo. Eso es previsible y no es, por sí solo, una señal de alarma: cualquier equipo que aprende un sistema nuevo trabaja más lento las primeras semanas.
Lo que sí es una señal de alarma es que la curva no vuelva a subir. Si meses después de lo previsto el equipo sigue tan lento como al inicio, o si el proyecto ni siquiera ha llegado a la fecha de salida para empezar esa curva, alguna de las cinco causas anteriores está deteniendo la recuperación, y vale la pena nombrarla en vez de seguir esperando a que se resuelva sola.
Qué hacer si tu proyecto tiene una de estas señales hoy
Ninguna de estas cinco causas se resuelve con más presión sobre el mismo equipo que ya lleva meses sin dar la fecha. Se resuelve con un diagnóstico que diga, con nombre y apellido, cuál de las cinco está pasando en tu caso y qué tan lejos está la salida a producción de verdad.
- Si el alcance creció, hay que volver a acotarlo por escrito antes de seguir configurando.
- Si el equipo cambió, hay que documentar lo que sabe el equipo actual antes de perder a alguien más.
- Si los datos no están limpios, hay que decidir qué se migra, qué se depura y qué se descarta.
- Si nadie del negocio ha validado, esa prueba tiene que pasar antes de fijar cualquier fecha nueva.
Ninguno de estos cuatro pasos exige decidir de entrada entre rescatar lo que hay o reimplementar desde cero. Esa decisión viene después, y conviene tomarla con datos de las cinco causas ya identificadas, no con la frustración acumulada de meses sin fecha.
Si reconoces una o varias de estas señales en tu proyecto, el autodiagnóstico de rescate es el primer paso: diez preguntas y un resultado inmediato sobre en qué tan grave está el punto donde se detuvo.
Dónde atendemos esto
¿Te está pasando algo parecido?
Cuéntanos qué sistema tienes y qué es lo que hoy no puedes hacer. La primera conversación es para entender.
Pedir un diagnóstico
Guía gratuita · 18 páginas
De Excel a ERP: la guía para saber si ya es momento
Lo que te diríamos en una primera reunión de diagnóstico, por escrito: cómo saber si necesitas un ERP, cuánto cuesta en rangos estimados y cómo migrar sin detener la operación.
- Las 7 señales de que ya no cabes en Excel
- Cuánto cuesta un ERP y de qué depende
- Los 5 errores que más cuestan
- Un checklist para decidir si ya es momento