Integración 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 órbita a su alrededor: las ventas alimentan la facturación, la facturación alimenta la contabilidad, la contabilidad alimenta el reporting. Cuando el ERP está aislado, la empresa funciona con silos de datos y procesos manuales de reconciliación. Cuando está bien integrado, la información fluye automáticamente y los errores humanos desaparecen.
El problema es que “bien integrado” es raro. Después de implementar integraciones ERP para clientes que usan Holded, SAP Business One, Odoo, A3 y Sage, hemos visto los mismos patrones de éxito y fracaso repetirse. Este executive brief documenta ambos.
Patrones que funcionan
API-first: el ERP como servicio
El patrón más sólido es tratar el ERP como un servicio con API (lo que detallamos en nuestro artículo sobre diseño API-first), no como una base de datos con interfaz. Todas las lecturas y escrituras pasan por la API del ERP. Ningún sistema externo toca la base de datos directamente.
¿Por qué? Porque la API del ERP encapsula la lógica de negocio. Cuando creas una factura vía API, el ERP aplica las reglas de numeración, 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 después durante la auditoría no es divertido.
La implementación práctica:
- Middleware de integración que centraliza la comunicación. 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 único punto de contacto con la API del ERP.
- Rate limiting y retry: las APIs de ERPs cloud (Holded, Zoho) tienen límites de llamadas. 100 requests/minuto es común. 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 operación de escritura debe ser idempotente. Si la integración reintenta una creación de factura porque el timeout fue ambiguo, no debe crear una factura duplicada. El patrón: verificar existencia por referencia externa antes de crear.
Event-driven: reaccionar en lugar de preguntar
En lugar de consultar periódicamente al ERP (“¿hay facturas nuevas?”), los eventos permiten que el ERP notifique cuando algo cambia. Es un patrón clásico de Enterprise Integration Patterns: la diferencia entre polling y push. Y la diferencia en latencia y eficiencia es dramática.
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:
- Ocurre un evento en el ERP (nueva factura)
- El ERP envía un webhook al middleware
- El middleware procesa el evento (actualizar CRM, enviar email, registrar pago)
- 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 reconciliación cada hora detecta eventos perdidos.
Sincronización bidireccional con fuente de verdad
Cuando dos sistemas necesitan compartir datos (el CRM tiene contactos, el ERP tiene clientes), la tentación es sincronización bidireccional: cambios en cualquier lado se propagan al otro. Es elegante en el diagrama. Es un infierno en producción.
¿Qué pasa cuando el mismo registro se modifica en ambos sistemas simultáneamente? ¿Quién gana? ¿El CRM actualizó el teléfono y el ERP actualizó el email del mismo contacto a las 14:03? Sin una regla clara, la sincronización se convierte en un generador de conflictos.
El patrón que funciona: definir una fuente de verdad por campo, no por registro. El CRM es fuente de verdad para datos comerciales (teléfono, 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 ningún campo se escribe desde dos sitios.
La implementación requiere un mapa de campos explícitamente documentado:
| Campo | Fuente de verdad | Dirección |
|---|---|---|
| Nombre | CRM | CRM -> ERP |
| CRM | CRM -> ERP | |
| NIF | ERP | ERP -> CRM |
| Condiciones pago | ERP | ERP -> CRM |
| Saldo pendiente | ERP | ERP -> CRM (solo lectura) |
Patrones que no funcionan
Integración directa a base de datos
Conectar sistemas directamente a la base de datos del ERP es el patrón más común y el más 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 lógica de negocio: como mencionamos arriba, insertar datos directamente evita validaciones, cálculos y efectos secundarios que la aplicación espera.
- Acoplamiento al schema: un cambio de versión del ERP modifica tablas internas y rompe todas las integraciones. Hemos visto esto ocurrir en actualizaciones de Sage que rompieron 4 integraciones simultáneamente.
- Sin auditoría: 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 patrón que funciona exactamente una vez: cuando lo pruebas con 10 registros. En producción, 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 única opción (algunos ERPs legacy no tienen otra), al menos: validar el formato antes de importar, registrar cada línea procesada, y nunca, jamás, procesar parcialmente un archivo sin log de lo que se procesó y lo que no.
El “sincronizamos todo en tiempo real”
La ambición de sincronizar todos los datos entre todos los sistemas en tiempo real parece lógica. En la práctica, 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 práctica: sincroniza en tiempo real solo lo que el negocio necesita en tiempo real. Los pedidos, sí. El catálogo de productos, probablemente no (un sync cada hora es suficiente). El histórico de facturas, definitivamente no.
El middleware como pieza crítica
El middleware de integración es la pieza que determina si la integración escala o colapsa. Las opciones:
Código custom (Python, Node): máximo control, mínimo coste de licencia, máximo coste de mantenimiento. Apropiado cuando la lógica de integración es compleja y específica.
iPaaS low-code (Make, n8n, Workato): rápido de implementar, visual, con conectores predefinidos para ERPs comunes. Apropiado para integraciones estándar. El riesgo: cuando la lógica se complica, el no-code se convierte en un laberinto de nodos más difícil de mantener que el código equivalente.
ESB/integration platform (MuleSoft, WSO2): para organizaciones con 10+ integraciones y requisitos de gobernanza. Overkill para la PYME típica.
Nuestra recomendación para empresas medianas españolas: empezar con código custom (un servicio Python o Node con cola de mensajes) para las 2-3 integraciones críticas. Si el número de integraciones crece a 5+, evaluar un iPaaS. Si crece a 10+, considerar un ESB.
Los números que importan
Métricas que toda integración ERP debería monitorizar:
- Latencia de sincronización: tiempo entre el evento en origen y la actualización en destino. Para facturación, debería ser < 5 minutos. Para catálogo, < 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 huérfanos: datos que existen en un sistema pero no en el otro. Una reconciliación semanal debería detectarlos. Cero es el objetivo; < 0.5% es aceptable.
- Cola de reintentos: cuántos eventos están pendientes de reintento. Si la cola crece consistentemente, el downstream no puede absorber el volumen.
Estas métricas deben estar en un dashboard visible. No en logs que nadie lee.
Si tu organización está planificando una integración ERP o necesita mejorar las existentes, nuestro equipo de desarrollo a medida diseña e implementa integraciones robustas. También ofrecemos consultoría para definir la arquitectura de integración antes de escribir una línea de código. Para integraciones específicas con Holded y Zoho, tenemos experiencia directa documentada en nuestras soluciones de logística.
