Integracion ERP: patrones que funcionan y los que no

El ERP es el centro, quieras o no

El ERP es el sistema gravitacional de cualquier empresa. Todo orbita a su alrededor: las ventas alimentan la facturacion, la facturacion alimenta la contabilidad, la contabilidad alimenta el reporting. Cuando el ERP esta aislado, la empresa funciona con silos de datos y procesos manuales de reconciliacion. Cuando esta bien integrado, la informacion fluye automaticamente y los errores humanos desaparecen.

El problema es que “bien integrado” es raro. Despues de implementar integraciones ERP para clientes que usan Holded, SAP Business One, Odoo, A3 y Sage, hemos visto los mismos patrones de exito y fracaso repetirse. Este executive brief documenta ambos.

Patrones que funcionan

API-first: el ERP como servicio

El patron mas solido es tratar el ERP como un servicio con API (lo que detallamos en nuestro articulo sobre diseño API-first), no como una base de datos con interfaz. Todas las lecturas y escrituras pasan por la API del ERP. Ningun sistema externo toca la base de datos directamente.

¿Por que? Porque la API del ERP encapsula la logica de negocio. Cuando creas una factura via API, el ERP aplica las reglas de numeracion, calcula impuestos, actualiza saldos de cliente y registra asientos contables. Cuando insertas un registro directamente en la base de datos, nada de eso ocurre. Y descubrir que falta un asiento contable tres meses despues durante la auditoria no es divertido.

La implementacion practica:

• Middleware de integracion que centraliza la comunicacion. Puede ser tan simple como un servicio Python/Node que orquesta las llamadas, o tan completo como un iPaaS (Workato, Make, n8n). Lo importante es que sea el unico punto de contacto con la API del ERP.
• Rate limiting y retry: las APIs de ERPs cloud (Holded, Zoho) tienen limites de llamadas. 100 requests/minuto es comun. El middleware debe implementar cola con backoff exponencial. Sin esto, las integraciones fallan en los momentos de mayor volumen (cierres de mes, campañas).
• Idempotencia: toda operacion de escritura debe ser idempotente. Si la integracion reintenta una creacion de factura porque el timeout fue ambiguo, no debe crear una factura duplicada. El patron: verificar existencia por referencia externa antes de crear.

Event-driven: reaccionar en lugar de preguntar

En lugar de consultar periodicamente al ERP (“¿hay facturas nuevas?”), los eventos permiten que el ERP notifique cuando algo cambia. Es un patron clasico de Enterprise Integration Patterns: la diferencia entre polling y push. Y la diferencia en latencia y eficiencia es dramatica.

Los ERPs modernos ofrecen webhooks: Holded puede enviar un POST cuando se crea una factura, Zoho cuando se actualiza un contacto, Stripe cuando se procesa un pago. El flujo es:

1. Ocurre un evento en el ERP (nueva factura)
2. El ERP envia un webhook al middleware
3. El middleware procesa el evento (actualizar CRM, enviar email, registrar pago)
4. Si el procesamiento falla, el evento se encola para reintento

Los webhooks no son 100% fiables. Se pierden, llegan duplicados, llegan desordenados. La arquitectura debe asumir esto:

• At-least-once delivery: diseñar para recibir el mismo evento dos veces. Idempotencia, de nuevo.
• Event store: guardar todos los eventos recibidos, procesados o no. Permite replay si algo falla y es invaluable para debugging.
• Fallback a polling: incluso con webhooks, un polling de reconciliacion cada hora detecta eventos perdidos.

Sincronizacion bidireccional con fuente de verdad

Cuando dos sistemas necesitan compartir datos (el CRM tiene contactos, el ERP tiene clientes), la tentacion es sincronizacion bidireccional: cambios en cualquier lado se propagan al otro. Es elegante en el diagrama. Es un infierno en produccion.

¿Que pasa cuando el mismo registro se modifica en ambos sistemas simultaneamente? ¿Quien gana? ¿El CRM actualizo el telefono y el ERP actualizo el email del mismo contacto a las 14:03? Sin una regla clara, la sincronizacion se convierte en un generador de conflictos.

El patron que funciona: definir una fuente de verdad por campo, no por registro. El CRM es fuente de verdad para datos comerciales (telefono, email, propietario). El ERP es fuente de verdad para datos financieros (saldo, facturas, condiciones de pago). Cada campo tiene un dueño. Los conflictos son imposibles porque ningun campo se escribe desde dos sitios.

La implementacion requiere un mapa de campos explicitamente documentado:

Campo	Fuente de verdad	Direccion
Nombre	CRM	CRM -> ERP
Email	CRM	CRM -> ERP
NIF	ERP	ERP -> CRM
Condiciones pago	ERP	ERP -> CRM
Saldo pendiente	ERP	ERP -> CRM (solo lectura)

Patrones que no funcionan

Integracion directa a base de datos

Conectar sistemas directamente a la base de datos del ERP es el patron mas comun y el mas destructivo. Los motivos para hacerlo son comprensibles: la API es lenta, la API no expone todos los campos, el equipo de desarrollo conoce SQL mejor que REST.

Los motivos para no hacerlo:

• Saltarse la logica de negocio: como mencionamos arriba, insertar datos directamente evita validaciones, calculos y efectos secundarios que la aplicacion espera.
• Acoplamiento al schema: un cambio de version del ERP modifica tablas internas y rompe todas las integraciones. Hemos visto esto ocurrir en actualizaciones de Sage que rompieron 4 integraciones simultaneamente.
• Sin auditoria: las escrituras directas no aparecen en el log de actividad del ERP. Para efectos legales y de compliance (especialmente SII y obligaciones fiscales), esto es un problema serio.

File-based integration (el CSV de la muerte)

Exportar datos del ERP a CSV, procesarlos con un script, e importar el resultado de vuelta. Es un patron que funciona exactamente una vez: cuando lo pruebas con 10 registros. En produccion, con miles de registros, fallos parciales y caracteres especiales en nombres españoles (ñ, tildes), es un generador constante de incidencias.

Si un CSV es la unica opcion (algunos ERPs legacy no tienen otra), al menos: validar el formato antes de importar, registrar cada linea procesada, y nunca, jamas, procesar parcialmente un archivo sin log de lo que se proceso y lo que no.

El “sincronizamos todo en tiempo real”

La ambicion de sincronizar todos los datos entre todos los sistemas en tiempo real parece logica. En la practica, genera complejidad exponencial, consume recursos del ERP (que no fue diseñado para 10.000 API calls por hora), y produce una cascada de eventos que puede saturar el middleware.

La regla practica: sincroniza en tiempo real solo lo que el negocio necesita en tiempo real. Los pedidos, si. El catalogo de productos, probablemente no (un sync cada hora es suficiente). El historico de facturas, definitivamente no.

El middleware como pieza critica

El middleware de integracion es la pieza que determina si la integracion escala o colapsa. Las opciones:

Codigo custom (Python, Node): maximo control, minimo coste de licencia, maximo coste de mantenimiento. Apropiado cuando la logica de integracion es compleja y especifica.

iPaaS low-code (Make, n8n, Workato): rapido de implementar, visual, con conectores predefinidos para ERPs comunes. Apropiado para integraciones estandar. El riesgo: cuando la logica se complica, el no-code se convierte en un laberinto de nodos mas dificil de mantener que el codigo equivalente.

ESB/integration platform (MuleSoft, WSO2): para organizaciones con 10+ integraciones y requisitos de gobernanza. Overkill para la PYME tipica.

Nuestra recomendacion para empresas medianas españolas: empezar con codigo custom (un servicio Python o Node con cola de mensajes) para las 2-3 integraciones criticas. Si el numero de integraciones crece a 5+, evaluar un iPaaS. Si crece a 10+, considerar un ESB.

Los numeros que importan

Metricas que toda integracion ERP deberia monitorizar:

• Latencia de sincronizacion: tiempo entre el evento en origen y la actualizacion en destino. Para facturacion, deberia ser < 5 minutos. Para catalogo, < 1 hora es aceptable.
• Tasa de error: porcentaje de operaciones que fallan. Objetivo: < 0.1%. Si supera el 1%, hay un problema de diseño.
• Registros huerfanos: datos que existen en un sistema pero no en el otro. Una reconciliacion semanal deberia detectarlos. Cero es el objetivo; < 0.5% es aceptable.
• Cola de reintentos: cuantos eventos estan pendientes de reintento. Si la cola crece consistentemente, el downstream no puede absorber el volumen.

Estas metricas deben estar en un dashboard visible. No en logs que nadie lee.

Si tu organizacion esta planificando una integracion ERP o necesita mejorar las existentes, nuestro equipo de desarrollo a medida diseña e implementa integraciones robustas. Tambien ofrecemos consultoria para definir la arquitectura de integracion antes de escribir una linea de codigo. Para integraciones especificas con Holded y Zoho, tenemos experiencia directa documentada en nuestras soluciones de logistica.