Rescatar o reimplementar un ERP: cómo decidir

Después de reconocer que un proyecto de ERP se atoró o salió mal, llega la pregunta que de verdad cuesta responder: ¿se arregla lo que hay, o se empieza de nuevo? La respuesta casi nunca es obvia, y equivocarla sale caro en cualquiera de los dos sentidos.

Este artículo da los criterios para decidir con datos, no con el instinto de quien lleva meses frustrado con el sistema.

Es una decisión que conviene tomar una sola vez y bien. Cambiar de rumbo a la mitad, empezar un rescate y descubrir tres meses después que en realidad hacía falta reimplementar, cuesta más que haber tomado la decisión correcta desde el inicio con la información completa sobre la mesa.

Qué significa cada opción en tiempo y en costo

Rescatar es corregir lo que ya existe: ajustar configuración, limpiar datos, cerrar procesos que quedaron sin definir, capacitar al equipo que nunca recibió capacitación completa. Se mide en semanas o pocos meses, porque parte de una base que ya funciona en algo.

Reimplementar es rehacer el diseño desde el inicio, conservando lo que sirve y descartando lo que no. Se mide en meses, similar a una implementación nueva, porque en la práctica lo es. Suele costar más que un rescate, y también resuelve problemas que un rescate no puede tocar.

La opción equivocada en cualquier dirección sale cara: rescatar un sistema que necesitaba rediseño completo solo pospone el mismo problema, y reimplementar un sistema que en realidad funcionaba gasta tiempo y presupuesto en resolver algo que no era la causa.

Hay un tercer costo que rara vez se cuenta: el desgaste del equipo que ya vivió una implementación mala. Cada nueva ronda, sea rescate o reimplementación, se apoya en la misma gente que va a operar el sistema, y esa gente llega con menos paciencia y más escepticismo que en el proyecto original. Elegir bien la primera vez también protege eso.

Señales de que conviene rescatar lo que hay

El rescate suele ser la respuesta correcta cuando el sistema en el fondo funciona y el problema está en otra parte.

• El sistema procesa correctamente las operaciones que sí se configuraron; el problema son los módulos o procesos que quedaron a medias.
• Los datos migrados son razonablemente confiables, con excepciones puntuales que se pueden identificar y corregir.
• El equipo nunca recibió capacitación completa y compensa con hojas de cálculo lo que el sistema ya podía hacer.
• El diseño original sí correspondía a la operación, pero la ejecución del proyecto se quedó corta.

Señales de que conviene reimplementar desde cero

La reimplementación entra cuando el problema no es de ejecución sino de diseño: lo que se construyó no corresponde a cómo opera realmente el negocio.

• Los procesos configurados no reflejan cómo trabaja la empresa hoy, ni cómo trabajaba cuando arrancó el proyecto.
• La estructura base, como el catálogo de cuentas o la definición de empresas y países, tiene errores de fondo que no se corrigen con ajustes puntuales.
• La migración de datos se hizo mal desde el origen y hay que rehacerla, no solo depurarla.
• El sistema no alcanza para el volumen o la complejidad actual de la operación, más allá de cómo esté configurado.

Cuando la respuesta es mixta

En la práctica, pocos proyectos caen limpiamente en una sola categoría. Es común que un módulo esté bien diseñado y otro necesite rehacerse desde el planteamiento, o que el proceso esté correcto pero los datos que lo alimentan estén tan mal migrados que conviene tratarlos como si fuera una reimplementación solo en esa parte.

Cuando pasa esto, la decisión no es rescatar todo o reimplementar todo. Es dividir el proyecto por módulo o por proceso, y aplicar a cada uno el tratamiento que le corresponde según su propio diagnóstico, aunque eso signifique correr dos ritmos distintos dentro del mismo proyecto durante un tiempo.

Cómo se ve un diagnóstico que responde esta pregunta con datos

La forma de no decidir a ciegas es separar el proceso, los datos y el sistema como tres causas distintas, en vez de juntarlas en una sola sensación de que el ERP no sirve. Un diagnóstico revisa cada uno por separado: qué tanto del proceso configurado sí corresponde a la operación, qué tan limpios están los datos, y si el sistema en sí es capaz de sostener lo que la empresa necesita.

Ese mismo documento sirve después para justificar la decisión frente a quien apruebe el presupuesto, sea el director general o un comité. Es distinto pedir recursos diciendo «el sistema no funciona» que llegar con una tabla que muestra, módulo por módulo, cuál se rescata y cuál se rehace, y por qué.

Con esos tres frentes evaluados por separado, la decisión entre rescatar y reimplementar deja de ser una apuesta y se convierte en una cuenta: cuánto cuesta cada ruta, cuánto tiempo toma, y qué riesgo queda si se elige la más corta.

Esa cuenta también sirve para algo más difícil de aceptar en el momento: a veces el diagnóstico muestra que ninguna de las dos rutas se justifica todavía, y que conviene sostener el sistema como está, con soporte puntual, mientras la empresa resuelve otras prioridades. No es la respuesta más común, pero es una respuesta válida, y un diagnóstico honesto la deja abierta hasta el final en vez de cerrarla de antemano.

Si estás en ese punto de decisión, el autodiagnóstico de rescate da una primera lectura en minutos, con diez preguntas sobre el estado del proyecto.

Otras entradas

Rescate de proyectos ERP

Qué hacer cuando el proveedor deja el proyecto de ERP a la mitad

Rescate de proyectos ERP

Tu ERP no sale a producción: cinco causas frecuentes

Cumplimiento fiscal en México

CFDI 4.0, DIOT y contabilidad electrónica: qué automatiza un ERP y qué sigue siendo manual