Un ERP no corrige por sí solo una organización confusa
Cuando una empresa pide un ERP, a veces está describiendo otra necesidad: saber qué está ocurriendo, evitar que la información se repita, aclarar quién decide o dejar de depender de una persona concreta. El software puede ayudar, pero no debería confundirse con el diagnóstico.
Si los pedidos cambian de criterio según quién los tramita, si los datos llegan tarde o si una aprobación nunca ha quedado definida, implantar un producto nuevo no resuelve automáticamente el problema. Puede, de hecho, hacer más visible y más costoso un desorden que ya existía.
Antes de elegir producto hay que responder a tres preguntas: qué funcionamiento queremos mejorar, qué conviene conservar y qué alternativas existen.
Qué debe aclarar un diagnóstico antes de implantar un ERP
Un diagnóstico sigue una operación real de principio a fin: una venta, una compra, una orden de trabajo o una expedición, según la actividad. El recorrido muestra dónde empieza el trabajo, quién interviene, qué datos cambian y cómo se cierra.
También hay que identificar decisiones y excepciones. Quién autoriza un descuento, quién corrige un dato, quién resuelve una incidencia y qué ocurre cuando falta la persona que suele hacerlo. Sin esas respuestas es fácil elegir una herramienta que encaje en la demostración y falle en la rutina.
La revisión incluye datos maestros, documentos, accesos, integraciones, hojas de cálculo y herramientas auxiliares. No para convertirlo en una auditoría interminable, sino para distinguir lo que sostiene de verdad la operación de lo que simplemente se ha acumulado.
Los cinco entregables que permiten decidir con criterio
El primer entregable es un mapa del proceso actual: pasos, participantes, traspasos y excepciones. El segundo, una matriz de responsabilidades y decisiones que aclare quién prepara, valida, aprueba y responde.
El tercero es un inventario de datos y herramientas: qué sistema manda sobre cada información, dónde hay duplicidades y qué integraciones existen. El cuarto es un registro de dependencias y conocimiento crítico, especialmente si parte del funcionamiento vive en la memoria de una persona.
El quinto es una hoja de ruta priorizada. Separa lo urgente de lo conveniente, identifica qué puede resolverse sin cambiar de ERP y explica cuándo tendría sentido sustituirlo. Con esa información es más fácil contrastar propuestas de proveedores.
Ajustar, integrar, ampliar o sustituir: cuatro decisiones diferentes
Ajustar significa utilizar mejor el sistema existente: revisar datos, permisos, circuitos de aprobación o parametrización. Puede ser suficiente cuando el producto ya cubre la operación, pero se implantó con una configuración poco clara.
Integrar consiste en conectar el ERP con otra herramienta para que un dato no tenga que volver a escribirse. Ampliar supone añadir una pieza específica cuando el proceso necesita una función que el estándar no resuelve. Sustituir implica migrar datos, formar equipos, revisar licencias y asumir una transición operativa.
Ninguna opción es siempre mejor. Lo razonable es compararlas contra el problema identificado, la dependencia del proveedor, el coste total y la capacidad de la empresa para mantener el resultado.
Qué debe incluir el coste real de cambiar de ERP
El precio de la licencia es solo una parte. Un cambio puede incluir diagnóstico, parametrización, migración de datos, desarrollo, integraciones, formación, pruebas, doble operación durante el cambio y soporte posterior.
También conviene preguntar qué ocurre con informes personalizados, documentación vinculada, conexiones con transporte, comercio electrónico, Microsoft 365 o software de terceros. Si una dependencia queda fuera de la propuesta, el coste aparece después, cuando la operación ya está comprometida.
No existe una cifra honesta sin alcance y contexto. Lo que sí puede exigirse es que cada proveedor separe costes iniciales, recurrentes y variables, y explique cómo se gestionarán cambios, incidencias y salida futura.
Cómo evaluar una demostración sin dejarse llevar por la pantalla
Una demostración útil no debería limitarse a un recorrido limpio preparado por el proveedor. Conviene llevar un caso real: un pedido con un cambio, una aprobación pendiente, un documento incompleto o una excepción comercial que la empresa reconozca.
La demostración tiene que enseñar si es posible seguir una decisión, identificar a la persona responsable, consultar el dato correcto y resolver una incidencia sin recurrir a mensajes sueltos.
También debe quedar claro qué parte viene de serie, qué requiere desarrollo, qué necesita otra licencia y quién se hará cargo cuando cambie la versión. Esa información vale más que una lista larga de funcionalidades.
La primera fase no es implantar: es decidir
El alcance inicial debería permitir entender la operación, contrastar el mapa con las personas implicadas y acordar prioridades. Puede terminar en una integración pequeña, en una mejora de reporting, en la documentación de funciones o en una recomendación de cambio de ERP. El resultado no se decide antes de mirar.
Ese análisis puede terminar en una integración, un ajuste del sistema actual o un desarrollo específico. También puede confirmar que cambiar de ERP tiene sentido. La recomendación se formula después de revisar la operación, no antes.
