Integración ERP con software existente: patrones, preguntas y errores que evitar

Resumen: Conectar un ERP a los sistemas que ya tienes —un WMS de hace ocho años, un CRM vertical, hojas Excel que mueven datos críticos— es técnicamente viable, pero solo si el proyecto parte de un diagnóstico honesto. Este artículo explica los tres patrones de integración que funcionan en pymes españolas, qué preguntas debes hacer antes de firmar un contrato y cuándo tiene sentido reemplazar en lugar de conectar.

Tabla de contenidos

• Por qué la integración ERP importa más que el reemplazo
• Inventario previo: lo que debes mapear antes de cualquier conversación técnica
• Los tres patrones de integración que funcionan
• Qué preguntas hacer antes de contratar el proyecto
• Cuándo integrar no es la respuesta
• Cómo afecta el cumplimiento normativo a la arquitectura de integración
• TL;DR
• Lecturas recomendadas

Por qué la integración ERP importa más que el reemplazo

La mayoría de pymes que llegan a una conversación sobre software nuevo no parten de cero. Tienen un sistema de gestión que funciona en parte, una herramienta vertical que el equipo conoce bien y procesos que llevan años ajustados. Tirar todo eso y empezar desde cero tiene un coste real: formación, pérdida de histórico, resistencia interna y riesgo operativo durante la transición.

La integración ERP con software existente permite mantener lo que funciona, corregir lo que falla y añadir capacidad donde hay carencias. No es el camino fácil —requiere análisis más detallado que un reemplazo estándar—, pero en la mayoría de los casos es el camino correcto.

Las pymes que integran su ERP con sistemas legacy existentes reducen el tiempo de adopción en un 40-60 % respecto a implantaciones de reemplazo completo, según datos de proyectos de integración en el sector logístico español.

Inventario previo: lo que debes mapear antes de cualquier conversación técnica

Antes de hablar con ningún proveedor, necesitas responder estas preguntas sobre cada sistema que tienes:

• Qué datos produce y consume: maestros de artículos, pedidos, albaranes, facturas, movimientos de stock, datos de clientes.
• Con qué frecuencia se mueven esos datos: en tiempo real, por lotes nocturnos, manualmente.
• Qué formato tienen: base de datos SQL propia, ficheros CSV, XML, llamadas a una API REST, exportaciones Excel manuales.
• Quién es el dueño del sistema: si es software de terceros, si tienes acceso al esquema de base de datos, si el proveedor original sigue dando soporte.
• Qué pasa si ese sistema falla: si es crítico para la operativa diaria o si puede tener una ventana de mantenimiento.

Con ese mapa, cualquier técnico puede decirte en una primera reunión qué es integrable, qué requiere trabajo adicional y qué es mejor reemplazar. Sin él, la reunión se convierte en un ejercicio de adivinanzas.

Los tres patrones de integración que funcionan

APIs REST: el patrón preferido cuando los sistemas son modernos

Una API REST permite que dos sistemas intercambien datos en tiempo real mediante llamadas HTTP estándar. Si tu ERP expone endpoints documentados y el sistema con el que quieres conectarlo también, la integración es directa y mantenible.

Las ventajas son claras: los datos viajan en tiempo real, la lógica de negocio permanece en cada sistema y el mantenimiento se limita a controlar versiones de la API. El problema aparece cuando uno de los sistemas es legacy y no tiene API, o cuando la tiene pero está sin documentar y sin soporte activo.

ETL (Extract, Transform, Load): para mover datos entre sistemas con estructuras diferentes

El patrón ETL extrae datos de un sistema, los transforma para adaptarlos al formato del destino y los carga. Es la solución habitual cuando uno de los sistemas no tiene API o cuando el volumen de datos justifica procesamiento por lotes.

En pymes con sistemas de hace más de diez años, el ETL sigue siendo el patrón más fiable para sincronizar catálogos de productos, precios, históricos de ventas o movimientos de almacén. El riesgo es la latencia: los datos no son en tiempo real, sino con el desfase del ciclo de carga.

• Ciclos típicos en entornos de almacén: cada 15 minutos para stock, una vez al día para maestros.
• Herramientas habituales en proyectos a medida: scripts Python sobre PostgreSQL, tareas programadas en el servidor, conectores propios sobre el esquema de base de datos.

Conectores a medida: cuando nada estándar encaja

Cuando el sistema legacy no tiene API, no tiene esquema de base de datos accesible y el proveedor ya no existe o no da soporte, la solución es un conector a medida que lea directamente del sistema (a veces con técnicas de scraping de interfaz o lectura de ficheros de exportación) y alimente el ERP.

Es el patrón más caro de mantener porque depende de que la estructura del sistema origen no cambie, pero en muchos casos es el único camino viable para no perder años de histórico o para mantener herramientas verticales muy específicas —sistemas de pesaje, terminales de código de barras propietarios, software de producción sectorial— que no tienen sustituto directo.

Qué preguntas hacer antes de contratar el proyecto

Antes de firmar cualquier propuesta de integración ERP, plantea estas preguntas directamente al proveedor:

1. ¿Habéis integrado antes este sistema concreto o uno similar? Pide referencias verificables.
2. ¿El ERP que proponéis expone una API documentada y versionada, o la integración depende del acceso directo a la base de datos?
3. ¿Qué pasa si el sistema origen cambia de versión o de proveedor? ¿Cómo afecta al mantenimiento del conector?
4. ¿Quién es el responsable técnico del proyecto y tiene acceso directo al código, o subcontratáis el desarrollo?
5. ¿Cómo gestionáis los errores de sincronización? ¿Hay un log auditable y alertas automáticas cuando un dato no se transfiere correctamente?
6. ¿El contrato incluye un periodo de estabilización tras el go-live, con SLA definido?
7. ¿Los datos se alojan en servidores en España y el proyecto cumple con el RGPD desde el diseño, no como añadido posterior?

Una propuesta que no responde con claridad estas preguntas antes de la firma es una propuesta que no puedes evaluar correctamente.

Cuándo integrar no es la respuesta

Integrar tiene sentido cuando el sistema existente aporta valor real —histórico de datos limpio, lógica de negocio específica, familiaridad del equipo— y el coste de mantenimiento del conector es menor que el coste de reemplazarlo.

No tiene sentido cuando:

• El sistema origen tiene errores de datos estructurales que se arrastran desde años atrás y que el conector reproduciría en el ERP nuevo.
• El proveedor del sistema legacy ha desaparecido y no hay documentación técnica accesible.
• La herramienta a integrar cubre una función que el ERP nuevo ya incluye de serie con mejor calidad.
• El coste de mantenimiento del conector supera el 30 % del coste total de la licencia anual del sistema integrado.

En esos casos, reemplazar con una migración de datos bien planificada es más eficiente que construir un puente sobre una base inestable.

Cómo afecta el cumplimiento normativo a la arquitectura de integración

Este punto se omite con frecuencia en las fases de análisis y aparece como problema en producción.

Verifactu obliga a que los sistemas de facturación registren cada factura en un registro de eventos inmutable y la envíen a la AEAT en tiempo real o con una latencia máxima de cuatro días. Si tu ERP nuevo se integra con un sistema de ventas legacy que genera facturas, necesitas decidir qué sistema es el titular del registro Verifactu. No pueden serlo los dos, y el conector entre ambos debe garantizar que ninguna factura queda sin registrar.

RGPD: si el conector mueve datos de clientes entre sistemas, necesitas documentar ese flujo en tu registro de actividades de tratamiento. Si uno de los sistemas está alojado fuera de la UE, tienes un problema de transferencia internacional de datos que resolver antes de arrancar el proyecto.

Construir la arquitectura de integración sin tener esto resuelto no es un riesgo técnico, es un riesgo legal con sanciones medibles.

En Rowan Tech incluimos el cumplimiento Verifactu y RGPD en el diseño de cualquier integración, no como módulo adicional. Si quieres ver cómo afecta esto a un proyecto concreto, puedes consultarnos directamente desde nuestra página de contacto.

TL;DR

• Antes de cualquier proyecto de integración ERP, mapea qué datos produce cada sistema, con qué frecuencia y en qué formato.
• Los tres patrones que funcionan en pymes son: APIs REST para sistemas modernos, ETL para datos por lotes entre sistemas con estructuras distintas y conectores a medida para sistemas legacy sin API.
• Haz siete preguntas concretas antes de firmar: referencias, documentación de la API, plan de mantenimiento, titularidad del código, gestión de errores, SLA post-go-live y cumplimiento RGPD.
• Integrar no siempre es la respuesta: si el sistema origen tiene datos sucios o el coste del conector supera el 30 % del coste anual del sistema, reemplazar puede ser más eficiente.
• Verifactu obliga a definir qué sistema es el titular del registro de facturación antes de arrancar la integración; no es una decisión que puedas aplazar.

Lecturas recomendadas

• Rowan ERP: ERP a medida para pymes españolas
• Rowan SGA: gestión de almacén con trazabilidad en tiempo real
• Rowan Analytics: Business Intelligence conectado a tu ERP o base de datos