Cómo conectar tu ERP con tu CRM sin romper nada

01 / 09Por qué conectar (y por qué suele salir mal)

En casi todas las empresas con ERP y CRM pasa lo mismo: el comercial da de alta al cliente en el CRM, alguien de administración lo vuelve a teclear en el ERP y, a partir de ahí, cada sistema evoluciona por su cuenta. La dirección de envío cambia en uno y no en el otro. El comercial no sabe si el pedido salió ni si la factura está pagada. Y los informes de ventas y de facturación dan cifras distintas porque beben de fuentes distintas.

Conectar los dos sistemas resuelve eso, pero solo si antes se responden unas cuantas preguntas que no son técnicas. La mayoría de integraciones que fallan no fallan por la API: fallan porque nadie decidió qué sistema tenía razón cuando los dos decían cosas distintas.

Si quieres ponerle número a lo que os cuesta hoy teclear los datos dos veces, prueba la calculadora del coste de copiar datos a mano. Los números los pones tú.

02 / 09Primero: quién manda en cada dato

El dato maestro es el sistema que tiene la última palabra sobre un dato. Si el CRM y el ERP discrepan sobre el NIF de un cliente, gana el maestro. Definirlo por escrito, dato a dato, es el paso que más problemas ahorra después.

Un reparto habitual, que sirve como punto de partida y luego se ajusta a cada empresa, es este:

Fíjate en que casi nada viaja en los dos sentidos. Cuando un dato puede editarse en los dos sistemas, hay que definir una regla de conflicto (por ejemplo, «gana el último cambio» o «gana siempre el ERP»), y esas reglas son la fuente principal de sorpresas. Cuantos menos datos bidireccionales, más fácil de mantener.

Una regla práctica: lo que tiene que ver con vender (seguimiento, conversaciones, previsiones) vive en el CRM; lo que tiene que ver con servir y cobrar (pedidos, albaranes, facturas, contabilidad) vive en el ERP. El CRM puede enseñar pedidos y facturas, pero no debería poder modificarlos.

03 / 09El identificador común: la pieza que evita duplicados

Para que la integración sepa que «Industrias Norte, S.L.» del CRM es el cliente 004512 del ERP, los dos registros tienen que compartir una clave. Sin ella, cada sincronización es una apuesta: o se crea un duplicado o se actualiza el cliente equivocado.

• Guarda el identificador del otro sistema en un campo de cada registro: el código de cliente del ERP en la ficha del CRM y, si el ERP lo permite, el ID del CRM en el ERP.
• Usa el NIF/CIF como clave de emparejamiento inicial, no como clave permanente: hay clientes sin NIF todavía, NIF mal escritos y grupos con varias sociedades.
• Deduplica antes de conectar. Si hoy tienes el mismo cliente tres veces en el CRM, la integración no lo arregla: lo multiplica.
• Define qué pasa con los registros huérfanos: clientes del ERP que no existen en el CRM (¿se crean? ¿se ignoran?) y al revés.

04 / 09Cómo se conectan: API, conector, plataforma o fichero

Hay cuatro formas habituales de mover datos entre un ERP y un CRM. Ninguna es mejor en abstracto: depende de qué permite tu ERP, del volumen y de quién va a mantenerlo.

Con ERPs como Navision, Sage o SAP la conexión suele ser posible por API o por servicios web, aunque depende de la versión y de cómo esté instalado. Con ERPs a medida, lo primero es ver qué expone: a veces hay una API, a veces hay que acordar con quien lo mantiene una vista de base de datos o un intercambio de ficheros.

Nuestra forma de verlo: usamos Make y n8n cuando encajan, y desarrollamos una capa propia cuando las reglas lo piden. Lo que no hacemos es forzar una herramienta porque sea la que tenemos a mano. Si dudas entre algo estándar y un desarrollo propio, el test ¿a medida o estándar? te da una primera respuesta. Si quieres ver flujos concretos ya resueltos, en la biblioteca de automatizaciones hay ejemplos por área.

05 / 09Un flujo tipo, paso a paso

Veamos el flujo más común: una oportunidad que se gana en el CRM y acaba como pedido y factura en el ERP, con el comercial viendo en todo momento en qué punto está.

1. El comercial mueve la oportunidad a «Ganada». El CRM lanza un evento.
2. La integración comprueba que el cliente tiene los datos que el ERP exige (NIF, dirección fiscal, forma de pago). Si falta algo, no envía nada: crea una tarea al comercial diciendo qué falta.
3. Si el cliente no existe en el ERP, lo da de alta y guarda en la ficha del CRM el código que devuelve el ERP. Si ya existe, lo reutiliza.
4. Crea el pedido en el ERP con las líneas de la oportunidad.
5. A partir de ahí, cada cambio de estado del pedido y cada factura vuelven a la ficha del cliente en el CRM, en modo lectura.

06 / 09Qué pasa cuando algo falla

Algo va a fallar: el ERP estará en mantenimiento una noche, alguien dará de alta un cliente sin código postal o una API devolverá un error que nadie había visto. Lo que distingue una integración seria de un apaño es qué pasa entonces.

• Registro de cada operación. Qué se intentó enviar, cuándo, con qué datos y qué respondió el otro sistema. Sin registro, cada incidencia es una investigación.
• Reintentos automáticos para errores temporales (el otro sistema no responde), con un límite y un tiempo de espera creciente.
• Operaciones idempotentes: si el mismo pedido se envía dos veces por un reintento, no se crean dos pedidos. Se consigue comprobando antes si ya existe, usando el identificador.
• Avisos a una persona concreta cuando un error no se resuelve solo, con el enlace al registro afectado. Un correo genérico a «informática» no es un aviso.
• Cola de pendientes visible: una lista de lo que no se ha podido sincronizar, para revisarla y relanzarla.

07 / 09Pruebas, carga inicial y arranque

Una integración entre ERP y CRM toca datos de facturación, así que no se prueba en producción. El orden que seguimos es este:

1. Entorno de pruebas. Una copia del ERP o una empresa de pruebas dentro de él, y un CRM de pruebas o un embudo aislado. Si el ERP no tiene entorno de pruebas, se acota mucho lo que se prueba contra producción y se hace con registros ficticios marcados.
2. Casos de prueba escritos: cliente nuevo, cliente existente, cliente sin NIF, pedido con varias líneas, pedido anulado, factura rectificativa. Los raros son los que rompen.
3. Carga inicial: emparejar los clientes existentes y traer el histórico que se decida (por ejemplo, pedidos y facturas de un periodo acotado, no toda la vida de la empresa).
4. Arranque por partes: primero la lectura (el CRM ve pedidos y facturas del ERP), después la escritura (el CRM crea clientes y pedidos). Si algo falla en la primera fase, no se ha tocado el ERP.
5. Convivencia vigilada durante los primeros días: revisar el registro a diario y comparar algunos pedidos a mano.

08 / 09Después del arranque

Una integración no es un proyecto que se cierra: es una pieza viva. El ERP se actualiza, el CRM cambia su API, la empresa añade un campo nuevo o una línea de negocio. Conviene dejar resuelto desde el principio:

• Quién es el responsable interno de la integración y quién el técnico que la mantiene.
• Documentación mínima: qué datos viajan, en qué dirección, con qué frecuencia y qué hacer ante cada tipo de aviso.
• Cómo se pide un cambio (un campo nuevo, una regla distinta) y cómo se prueba antes de pasarlo a producción.
• Qué se revisa tras cada actualización del ERP o del CRM.

Si trabajas con Bitrix24, tenemos una página específica sobre integraciones de Bitrix24 con ERP, web y canales. Y si lo tuyo es un caso de sistemas variados, empieza por integraciones.

09 / 09Checklist antes de conectar