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

El correo dejó de contestarse. Las juntas semanales se volvieron mensuales y luego desaparecieron. O el contrato terminó exactamente en la fecha pactada, con el sistema a medio construir y sin nadie que se sienta responsable de terminarlo.

Sea cual sea la forma en que pasó, quedaste con un ERP a medias y una pregunta urgente: qué se hace ahora, antes de contratar a nadie más.

La reacción natural es salir a buscar un reemplazo de inmediato. Vale la pena resistir esa urgencia un par de semanas: lo que hagas primero determina si el siguiente proveedor cotiza sobre información real o sobre suposiciones, igual que las que llevaron al proyecto original a este punto.

Qué revisar primero: contratos, accesos y documentación

Antes de pensar en un siguiente proveedor, hay tres cosas que conviene confirmar mientras todavía es fácil hacerlo.

• El contrato: qué se entregó formalmente, qué quedó pendiente por escrito, y si hay una cláusula de propiedad sobre la configuración y el código construido.
• Los accesos: quién tiene las credenciales de administrador del sistema, del ambiente de pruebas y de cualquier integración conectada. Si el proveedor las controla, pídelas de vuelta antes de que sea más difícil.
• La documentación: qué manuales, diagramas de proceso o bitácoras de configuración existen. Es común que no exista casi nada, y eso también es información: dice cuánto trabajo de reconstrucción hace falta.

Ninguno de estos tres pasos requiere contratar a nadie todavía. Son tuyos, y entre más rápido se hagan, menos se pierde. Guarda copia de todo, incluso de lo que parezca menor: correos con decisiones de alcance, versiones anteriores de la configuración, respaldos de la base de datos. Cuando llegue el momento de evaluar qué se puede rescatar, esa evidencia vale más de lo que parece mientras el proyecto sigue activo.

Cómo evaluar qué se puede rescatar de lo ya construido

No todo lo que quedó a medias está mal hecho. Es común que una parte del sistema funcione correctamente y que el proyecto se haya detenido por otra razón: falta de capacitación, un alcance que nunca se cerró, o un equipo que simplemente se fue sin terminar.

Antes de descartar nada, conviene probar el sistema tal como quedó, con datos y procesos reales, no con la memoria de lo que se prometió en la venta. Muchas veces lo que se rescata termina siendo más de lo que el equipo interno asumía cuando el proveedor se fue, porque la frustración del abandono se proyecta sobre todo el sistema y no solo sobre la parte que de verdad falló.

Separar lo que sirve de lo que no requiere revisar tres frentes por separado: el proceso que se configuró, la calidad de los datos que ya se migraron, y si el sistema en sí alcanza para lo que la operación necesita. Tratar los tres como uno solo es lo que lleva a decisiones apresuradas, como desechar todo cuando solo una parte falla.

Errores comunes al buscar un segundo proveedor con prisa

La urgencia de resolver rápido es comprensible y también es la que más errores produce. Los más frecuentes:

• Pedir cotización antes de tener claro qué se puede rescatar, lo que produce propuestas que no comparan lo mismo entre sí.
• Contratar al proveedor que promete la fecha más corta, sin preguntar sobre qué base llegó a esa fecha.
• Asumir que hay que empezar de cero porque el proyecto anterior falló, sin haber revisado primero qué parte sí sirve.
• No involucrar al área que va a usar el sistema en la evaluación del nuevo proveedor, repitiendo el mismo error que dejó al proyecto anterior sin validar.

Qué tan urgente es actuar según en qué punto quedó el sistema

No todos los abandonos de proyecto tienen la misma urgencia. Si el sistema ya salió a producción y el proveedor solo dejó de dar seguimiento, la operación sigue corriendo y hay tiempo de evaluar con calma. Si el proyecto se detuvo antes de salir en vivo, la presión es distinta: cada semana sin decisión es una semana más operando sobre el sistema anterior o sobre hojas de cálculo, mientras la licencia del ERP nuevo sigue corriendo.

Esa diferencia también cambia qué tan a fondo hay que revisar antes de actuar. Un sistema que ya opera, aunque sea con fallas, deja rastro de qué funciona y qué no. Un proyecto que nunca llegó a producción solo tiene lo que quedó documentado, y por eso ahí la revisión de contratos y accesos es todavía más urgente.

Cuándo conviene un diagnóstico antes de contratar a nadie más

Un diagnóstico independiente, que no dependa de vender la siguiente etapa, resuelve el problema de fondo: te da un documento con qué funciona, qué no, y por qué, antes de que cualquier propuesta comercial entre a la conversación.

Con ese documento puedes pedir cotizaciones a distintos proveedores sobre el mismo alcance, en vez de recibir promesas que no se pueden comparar entre sí porque cada quien parte de un diagnóstico distinto, o de ninguno.

No hace falta que el proveedor anterior colabore para que ese diagnóstico se pueda hacer. La mayoría de los casos que se revisan bajo esta figura son exactamente eso: un proveedor que ya no está y una empresa que necesita entender, con alguien nuevo, en qué quedó su propio sistema.

Si tu proyecto está en este punto, el autodiagnóstico de rescate es un primer paso rápido: diez preguntas sobre en qué estado quedó el sistema y qué tan urgente es actuar.

Otras entradas

Rescate de proyectos ERP

Rescatar o reimplementar un ERP: cómo decidir

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