"Tenemos un CRM, tenemos un ERP, los dos guardan los mismos clientes y proveedores. Y cada vez que se cambia algo en uno, en el otro queda diferente." Si esta frase te resulta familiar, este artículo es para ti.
La integración CRM-ERP es uno de los proyectos donde más empresas se atascan: parece simple en la pizarra ("conectamos los dos por API y listo"), pero la realidad operativa tiene aristas que no se ven hasta que estás en producción. Vamos a ver el patrón correcto, que aplicamos en los proyectos de integraciones de Codevelia.
El error fundamental: pensar que es una sincronización
La trampa más común es plantear el problema como "sincronización bidireccional de datos entre A y B". Suena bien hasta que un cliente cambia su dirección en el CRM y, al mismo tiempo, contabilidad le cambia el NIF en el ERP. ¿Quién gana? ¿En qué orden se aplican? ¿Qué pasa si la API del ERP estaba caída cuando se cambió la dirección?
El planteamiento correcto es "propagación de eventos con resolución de conflictos". Suena más complicado, pero es el único modelo que aguanta producción real.
Pieza 1 · Determinar el "sistema de verdad" por entidad
Para cada tipo de dato, hay que decidir quién manda:
- Datos comerciales (lead, oportunidad, etiquetas, scoring) → CRM manda. El ERP los recibe sólo cuando se convierten en venta.
- Datos fiscales (razón social, NIF, dirección de facturación, condiciones de pago) → ERP manda. El CRM puede leerlos pero no editarlos.
- Datos de relación (notas comerciales, llamadas, próxima reunión) → CRM manda exclusivamente.
- Datos de operación (obras, partes, facturas) → ERP manda. Si el CRM los muestra, es read-only.
Esta decisión no es técnica, es organizativa: tienes que pactarla con comercial y con administración antes de escribir una sola línea de código. Si no, cada equipo intentará "arreglar" datos del otro sistema y se romperá la sincronía.
Pieza 2 · Webhooks, no polling
Polling = preguntar cada 5 minutos "¿hay algo nuevo?". Funciona, pero es ineficiente y siempre llega tarde. Webhooks = el sistema de origen avisa al integrador cuando hay un cambio, en el instante en el que ocurre.
La arquitectura correcta:
CRM → webhook al integrador → cola de mensajes → worker → API ERP¿Por qué la cola intermedia? Porque la API del ERP a veces falla, está saturada, o tarda. Si el CRM dispara webhook directo al ERP y el ERP no responde, pierdes el evento. La cola garantiza que el evento se reintenta hasta que se procesa correctamente.
Pieza 3 · Idempotencia obligatoria
Si un webhook se dispara dos veces (lo cual va a pasar — todos los sistemas reintentan), tu integrador no puede crear el cliente dos veces. Cada operación debe ser idempotente: ejecutarla N veces produce el mismo resultado que ejecutarla una.
El truco: cada evento lleva un event_id único. Antes de procesar, miras si ya lo procesaste. Si sí, lo descartas. Si no, lo procesas y guardas el event_id con su resultado. Suena trivial. Es lo que separa una integración estable de una integración que duplica datos cada miércoles.
Pieza 4 · Resolución de conflictos explícita
Aún con sistema-de-verdad bien definido, los conflictos ocurren: dos cambios concurrentes a la misma entidad, llegando casi al mismo tiempo. Hay tres estrategias:
- Last-write-wins: el último gana. Simple, pero se pierden datos. Sólo aceptable si los conflictos son raros.
- Merge automático: si los dos cambios afectan a campos diferentes, se aplican ambos. Si afectan al mismo campo, escala a humano. Es el más razonable en la práctica.
- Cola de revisión humana: ningún conflicto se aplica automáticamente; un operador decide. Costoso pero indispensable en datos fiscales o sensibles.
Nuestra recomendación: merge automático para datos comerciales, cola de revisión para datos fiscales.
Pieza 5 · Dead-letter queue
¿Qué pasa cuando un evento falla 5 veces seguidas? No se descarta. Va a una dead-letter queue: una cola separada con eventos no procesados, que un humano revisa cada día. Es el equivalente a la papelera del ordenador: lo que llega ahí está roto, pero nadie lo borra hasta haberlo mirado.
Sin dead-letter queue, los errores se pierden silenciosamente y descubres dos meses después que el 3% de tus clientes nuevos del CRM nunca llegaron al ERP.
Pieza 6 · Observabilidad desde el día uno
Necesitas saber, en todo momento:
- Cuántos eventos por hora se procesan
- Latencia P50/P95 entre cambio en origen y reflejo en destino
- Tasa de errores y de reintentos
- Tamaño de las colas (si crecen, hay un problema upstream)
Sin esto, navegas a ciegas. Una integración que "parece funcionar" puede llevar semanas perdiendo el 5% de los eventos sin que nadie lo note.
El stack que solemos elegir
No hay un único correcto, pero esto funciona bien y cuesta poco:
- Recepción de webhooks: un endpoint HTTP en Node.js o Bun, validando firma HMAC del origen.
- Cola: PostgreSQL con SKIP LOCKED (sí, basta) para volúmenes hasta ~10 eventos/segundo. Por encima, RabbitMQ o Redis Streams.
- Workers: procesos Node.js con concurrencia limitada y retry exponencial.
- Observabilidad: Prometheus + Grafana, paneles de tasa, latencia y cola.
Es boring, conservador y aguanta. Las integraciones no necesitan tecnología novedosa, necesitan tecnología confiable.
El antipatrón que nunca recomendamos
"Vamos a usar Zapier o Make para todo". Funciona para 5 escenarios y vuela en pedazos para el sexto. La razón: estos servicios no soportan transacciones distribuidas, no tienen dead-letter queues serias, y cuando rompen, depuras a ciegas. Para conexiones B2B serias, una integración custom bien hecha cuesta más de inicio pero mucho menos de operar.
¿Tienes un CRM y un ERP que no se hablan? Solicita un análisis técnico gratuito — te decimos en 30 minutos qué arquitectura es la correcta para tu caso.