Cambiar de ERP o CRM: señales de que el problema no es la herramienta

El ERP se ha quedado pequeño, el CRM no lo usa nadie, los informes no cuadran, el proveedor tarda en responder. En algún momento alguien lo pone sobre la mesa: "habría que cambiar de sistema". Es una de las decisiones más caras que toma una pyme, y no por la licencia: por la migración, los meses de convivencia entre lo viejo y lo nuevo, el aprendizaje de todo el equipo y las sorpresas que aparecen a mitad de camino. Antes de firmarla conviene responder una pregunta que casi nunca se hace despacio: ¿el problema es de verdad la herramienta? Porque si no lo es, el sistema nuevo hereda el problema, y lo hereda con factura.

Un sistema nuevo no trae orden: lo pide

La migración traslada los datos tal como están y a las personas tal como trabajan. Si hoy cada comercial rellena el CRM a su manera, mañana lo hará igual, en pantallas más bonitas. Si nadie sabe en qué momento un presupuesto se convierte en pedido, el ERP nuevo tampoco lo sabrá.

Un ERP o un CRM define dónde se guardan las cosas y qué pasos ofrece; no decide cómo trabaja tu empresa ni impone la disciplina de usarlo bien. Eso se decide fuera del software, y si no está decidido, el sistema —cualquier sistema— se limita a reflejar la ambigüedad con la que se le alimenta. Por eso tantos cambios de sistema decepcionan: se esperaba que la herramienta trajera el orden, cuando en realidad lo estaba pidiendo.

Tres señales de que el problema no es la herramienta

El proceso no está definido

Haz la prueba: pregunta a tres personas cómo se pasa de presupuesto a pedido, o cuándo un cliente pasa a estar "perdido". Si recibes tres respuestas, el sistema actual no está fallando: está ejecutando fielmente esa indefinición. Un software no puede ejecutar un proceso que no existe, y el nuevo tampoco podrá.

Los datos están sucios

Clientes duplicados, campos de texto libre donde debió haber una lista, estados que cada uno interpreta a su manera. Migrar datos sucios tiene doble coste: pagas por llevarlos al sistema nuevo y, encima, contaminas la primera impresión. Cuando el equipo estrena sistema y lo primero que ve es que "esto tampoco cuadra", la adopción —que es lo más frágil de todo el proyecto— muere en semanas.

Nadie es dueño del sistema

No hay un responsable funcional: nadie decide qué campos existen, quién tiene qué permisos, qué significa cada estado. Todo se fue añadiendo por peticiones puntuales a lo largo de los años. Sin un dueño, el sistema nuevo degenerará exactamente igual; solo que más rápido, porque estrena libertad y todo el mundo tiene peticiones acumuladas.

Si reconoces una o más de estas señales, cambiar de sistema no resuelve el problema: lo muda de casa.

Cuándo sí toca cambiar

El criterio honesto funciona en las dos direcciones. Hay razones legítimas para cambiar:

• El negocio ya no cabe en el modelo del sistema. Vendes servicios y el sistema piensa en almacén y referencias; trabajas por proyectos y el sistema solo entiende pedidos. Cuando el desajuste es de concepto, no de configuración, ningún ajuste lo salva.
• El producto está abandonado. El proveedor no evoluciona, el soporte no responde, cada actualización da miedo. Un sistema sin futuro es un riesgo, no un ahorro.
• Mantenerlo vivo cuesta más que sustituirlo. Cuando la operación diaria depende de una colección de apaños, exportaciones manuales y hojas de cálculo satélite que compensan lo que el sistema no hace, el coste del apaño ya es estructural.
• Hay un límite técnico real y comprobado. No se puede integrar con nada, no hay forma razonable de sacar los datos, no soporta algo que el negocio necesita de verdad. Comprobado significa eso: verificado con el proveedor actual, no supuesto.

Fíjate en que ninguna de estas razones es "el equipo no lo usa" ni "los datos no cuadran". Esas dos casi siempre apuntan a las señales del apartado anterior.

Si decides cambiar, cambia con el trabajo hecho

Incluso cuando el cambio está justificado, el orden de los pasos importa:

1. Define el proceso antes de elegir sistema. Elegir es comparar contra algo; sin proceso definido, la comparación la gana la mejor demo.
2. Limpia antes de migrar. Y decide qué histórico merece viajar: migrarlo todo por si acaso es pagar por trasladar el desorden.
3. Nombra al dueño antes del arranque. Quien decide campos, permisos y criterios tiene que existir el primer día, no aparecer cuando ya hay que arreglar cosas.
4. Migra menos de lo que crees. Cada personalización y cada dato heredado que dejas fuera es mantenimiento futuro que te ahorras.

El mejor momento para poner orden es antes de la migración, no durante. Y a veces ese trabajo previo depara una sorpresa incómoda: hecho el orden, el sistema actual da mucho más de sí de lo que parecía. Un diagnóstico previo sirve precisamente para saberlo antes de firmar, no después.

Cinco preguntas antes de firmar el cambio

1. ¿Podemos describir, sin "depende", el proceso que el sistema nuevo tiene que ejecutar?
2. ¿Los datos que migraríamos están limpios, o migraríamos el desorden con ellos?
3. ¿Quién será el dueño del sistema nuevo, con nombre y apellidos?
4. ¿Qué es exactamente lo que el sistema actual no puede hacer, y lo hemos comprobado con el proveedor?
5. Si hiciéramos hoy la limpieza y el orden que exige la migración, ¿seguiríamos queriendo cambiar?

La quinta es la que más cambios de sistema evita. Y cuando la respuesta sigue siendo sí, es también la que hace que el cambio, esta vez, salga bien.