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

La integración entre el CRM y el ERP es la que más pide una empresa cuando crece, y la que más veces acaba en un cajón: se monta, funciona un tiempo, empieza a duplicar contactos o a perder pedidos, y alguien vuelve a copiar datos a mano «hasta que se arregle». No se arregla porque el problema no era técnico. Era de decisiones que nadie tomó antes de empezar.

Por qué se hace mal

El CRM sabe de clientes, oportunidades y presupuestos. El ERP sabe de pedidos, facturas, stock y contabilidad. Los dos guardan datos del mismo cliente, y en cuanto un dato vive en dos sitios aparece la pregunta que rompe integraciones: cuando los dos dicen algo distinto, ¿quién tiene razón?

Si esa pregunta no tiene respuesta escrita, la integración la contesta al azar cada vez. Y al azar significa que un comercial cambia la dirección de un cliente en el CRM, el ERP la sobrescribe con la antigua esa noche, y el paquete se envía a la dirección vieja.

Las cinco decisiones que hay que tomar antes

1. Qué sistema es el maestro de cada dato

No «cuál es el maestro»: cuál es el maestro de cada dato. Lo habitual es que el CRM mande en todo lo comercial (contacto, oportunidad, presupuesto) y el ERP en todo lo administrativo (pedido confirmado, factura, stock, condiciones de pago). Cuando el CRM dice una cosa del stock y el ERP otra, gana el ERP siempre, y al revés con el teléfono del contacto. Se escribe en una tabla de dos columnas y se firma.

2. En qué momento un cliente «existe» en el ERP

Un contacto que pide información no debería crear una ficha de cliente en el ERP: llenaría la contabilidad de clientes que nunca compraron. El momento habitual es el primer pedido confirmado o el primer presupuesto aceptado. Esa regla define cuándo la integración crea el cliente en el ERP y evita el problema más común: un ERP con tres mil clientes de los que compran trescientos.

3. Qué se sincroniza en tiempo real y qué por lotes

Un pedido confirmado en el CRM conviene que llegue al ERP en segundos: hay que reservar stock y preparar. Una actualización del cargo de un contacto puede viajar cada hora sin que pase nada. Todo en tiempo real es más caro, más frágil y consume los límites de la API sin aportar nada. Se decide dato a dato.

4. Cómo se identifica un registro en los dos lados

El cliente «Talleres García» del CRM y el «Talleres Garcia S.L.» del ERP tienen que ser el mismo, y el nombre no vale para saberlo. Hace falta un identificador común: el NIF, un código de cliente o un campo que guarde el identificador del otro sistema. Sin esto, cada sincronización crea duplicados, y a los seis meses hay cuatro «Talleres García».

5. Qué pasa cuando algo falla

Un sistema no responde, una API limita las peticiones, un registro llega con un campo obligatorio vacío. La integración tiene que reintentar lo que se pueda, guardar lo que no pudo entregar para intentarlo después, no duplicar nada cuando lo reintente, y avisar a alguien de lo que no se resolvió solo. Decidir esto antes es lo que separa una integración de un script.

Las tres formas de conectar

Conector nativo. Muchos CRM y ERP tienen integración oficial entre ellos. Es lo más rápido y lo menos flexible: sincroniza los campos que el fabricante decidió, con las reglas que el fabricante decidió. Vale si tus cinco decisiones coinciden con las suyas. Compruébalo antes de dar nada por hecho.

Herramienta de automatización sin código. Un flujo que escucha cambios en un sistema y los escribe en el otro. Rápido de montar, fácil de ajustar y adecuado para volúmenes moderados. Su límite aparece con las reglas de conflicto complejas y con el manejo de errores: cuando el flujo falla a las tres de la mañana, alguien tiene que haber previsto qué pasa.

Desarrollo a medida sobre las API. Un servicio propio que habla con los dos sistemas por API, con las reglas de negocio escritas en código, reintentos, idempotencia, registro de cada operación y avisos. Cuesta más al principio y menos cada mes, aguanta el volumen y es tuyo. Compensa cuando la integración es crítica para operar o cuando hay más de dos sistemas en juego.

En la práctica se mezclan: un conector nativo para lo estándar, un flujo para lo que cambia a menudo y desarrollo para el núcleo. Lo importante es que alguien lo decida y lo escriba.

Lo que falla a los seis meses

Cuatro cosas, siempre las mismas:

• Un proveedor cambia su API. Pasa. La integración monitorizada lo detecta en las primeras peticiones fallidas; la que no, deja de sincronizar y nadie se entera hasta que faltan pedidos.
• Un campo nuevo. Alguien añade un campo obligatorio en el ERP y la integración empieza a rechazar todo. Sin registro de errores, parece que «el CRM no funciona».
• Duplicados por identificación débil. La decisión cuatro, otra vez. Si se hizo por nombre, aparecen.
• Nadie sabe cómo funciona. La montó alguien que ya no está. Sin documentación, nadie se atreve a tocarla y se vuelve a copiar a mano.

Todas se evitan en el diseño. Ninguna se evita después.

Cómo lo abordamos

Empezamos por el inventario: qué versión tiene cada sistema, qué expone su API, con qué límites, y una tabla de datos con su maestro. Con eso, las cinco decisiones se toman en una reunión y quedan por escrito. Después se construye —con la forma que convenga a cada pieza—, se prueba con datos reales en un entorno aparte, y se pasa a producción con marcha atrás preparada. Y queda monitorizado: si algo se para, el aviso sale de nosotros.

El detalle del servicio está en integración y desarrollo de APIs. Y si no sabes por dónde empezar, el diagnóstico gratuito de media hora suele terminar con esta integración entre los tres procesos con más retorno.