Integrar un ERP heredado sin interrumpir el negocio

Antes de añadir nada, hay que saber qué entra y qué sale del ERP hoy. Ese inventario casi siempre descubre conexiones olvidadas: una hoja de cálculo que lee directamente una tabla, un script que exporta pedidos a un transportista o un informe que alguien genera a mano cada lunes. Si una de esas piezas se rompe durante la integración, el negocio lo notará antes que el equipo técnico.

Una forma eficaz de completar el inventario es combinar entrevistas con los usuarios clave y una revisión técnica de accesos a la base de datos, tareas programadas y carpetas de intercambio. Ninguna de las dos fuentes basta por separado.

La capa anticorrupción es un patrón descrito originalmente en el diseño guiado por el dominio y documentado, entre otros, en el centro de arquitectura de Microsoft: una capa intermedia que traduce entre el modelo del sistema heredado y el del sistema nuevo. Las aplicaciones nuevas hablan con esa capa en sus propios términos y nunca ven las tablas, los códigos crípticos ni las peculiaridades del ERP.

• Traduce estructuras: un pedido nuevo con líneas y estados claros se convierte en las cabeceras y detalles que espera el ERP.
• Traduce significados: códigos internos de serie, almacén o tipo de cliente se convierten en conceptos legibles.
• Valida en la frontera: rechaza datos incompletos antes de que lleguen al ERP, con un motivo comprensible.
• Registra cada intercambio con un identificador de correlación para poder seguirlo de punta a punta.
• Concentra en un único sitio el conocimiento sobre el ERP, de modo que sustituirlo más adelante afecte solo a la capa.

Cuando una función pasa del ERP a un sistema nuevo, conviene un periodo en el que ambos procesan la misma información y se comparan resultados. Es la idea que Martin Fowler describe con la imagen de la higuera estranguladora: el sistema nuevo crece alrededor del antiguo y asume funciones de una en una, con código de transición que permite que convivan hasta completar el traspaso.

1. Elegid una función acotada y con resultados verificables, por ejemplo el cálculo de tarifas o la generación de albaranes.
2. Haced que el sistema nuevo procese las mismas entradas que el ERP sin que su resultado tenga efecto real.
3. Comparad automáticamente ambas salidas y revisad cada diferencia hasta entender su causa.
4. Cuando las diferencias estén explicadas y aceptadas, haced que el resultado del sistema nuevo sea el válido.
5. Mantened el ERP como respaldo durante un periodo acordado antes de retirar la función.

El paralelo tiene coste: duplica procesamiento y exige revisar discrepancias. Para funciones de bajo riesgo puede bastar con una prueba sobre datos históricos. Para facturación, inventario o contabilidad suele merecer la pena.

Clientes, proveedores, artículos, tarifas y plan contable son la base sobre la que funciona todo lo demás. En un ERP con años de uso aparecen duplicados, códigos reutilizados, campos usados para fines distintos de su nombre y registros obsoletos que nadie se atreve a borrar. Migrarlos sin limpieza traslada el problema al sistema nuevo.

• Definir quién es propietario de cada maestro durante la convivencia y en qué sistema se edita.
• Perfilar los datos antes de migrar: duplicados, valores vacíos, formatos incoherentes.
• Acordar reglas de limpieza con las áreas de negocio, que son quienes saben si dos clientes son el mismo.
• Mantener una tabla de equivalencias entre códigos antiguos y nuevos mientras ambos sistemas coexistan.
• Ensayar la migración completa varias veces en un entorno de pruebas y medir cuánto dura.

Cada paso de la integración debería tener un plan de vuelta atrás escrito y probado. No basta con «restaurar una copia»: si durante unas horas se han registrado pedidos en el sistema nuevo, hay que decidir cómo se reincorporan al ERP. El rollback se diseña a la vez que el avance, no cuando algo ya ha fallado.

• Criterios objetivos para decidir la vuelta atrás: errores de facturación, colas bloqueadas, diferencias de inventario.
• Quién toma la decisión y en qué plazo máximo.
• Cómo se recuperan las operaciones registradas en el sistema nuevo durante el intento.
• Evitar cambios irreversibles en el ERP, como borrar tablas o campos, hasta que el nuevo flujo esté consolidado.
• Calendario: no hacer cambios relevantes cerca de un cierre contable o de una campaña fuerte.

Un ERP heredado lleva años moldeando la forma de trabajar. Los usuarios conocen sus atajos, sus fallos y sus trucos para salir del paso. Una integración técnicamente correcta fracasa si la gente sigue apuntando en una libreta porque no confía en la pantalla nueva. Implicar desde el inicio a usuarios clave de cada área, formar con datos reales y dar un canal claro para reportar problemas reduce ese riesgo.

Conviene también decidir qué se deja de hacer. Si el sistema nuevo asume una función, el procedimiento antiguo debe retirarse de forma explícita; de lo contrario, aparecerán registros duplicados en ambos lados.

1. ¿Existe un inventario completo de interfaces actuales, con responsable y criticidad?
2. ¿Está definido qué sistema manda en cada dato durante la convivencia?
3. ¿Hay una capa intermedia que aísle el ERP, o las aplicaciones nuevas leen sus tablas directamente?
4. ¿Qué funciones requieren ejecución en paralelo y cuáles basta con probar sobre datos históricos?
5. ¿Se ha ensayado la migración de maestros y el plan de vuelta atrás?
6. ¿Está el calendario alejado de cierres y campañas, y cuenta con usuarios clave implicados?

Si alguna respuesta es negativa, no significa que el proyecto no sea viable, sino que ese es el siguiente trabajo que hay que hacer antes de tocar el ERP. Para estimar el esfuerzo de las interfaces, la guía sobre el coste de una integración entre sistemas detalla los factores que más pesan.