Integrar ERP y CRM sin romper nada: patrones, fuente de verdad y errores que cuestan meses

La integración ERP CRM es uno de esos proyectos que empiezan con una frase inocente en un comité —«que el comercial vea el stock»— y terminan doce meses después con dos sistemas medio sincronizados, un Excel intermedio que nadie quiere tocar y una persona de administración corrigiendo a mano lo que el conector duplica cada noche. No pasa por falta de tecnología: hoy casi todo se conecta. Pasa porque se salta la parte aburrida, que es decidir quién manda sobre cada dato antes de escribir una sola línea de código.

Esta guía va de eso: de los patrones que funcionan, de cómo fijar la fuente de verdad, de en qué orden se despliega para no parar el negocio y de los errores concretos que hemos visto convertir un proyecto de ocho semanas en uno de ocho meses.

¿Qué es la integración ERP CRM y qué no es?

Integrar ERP y CRM es hacer que dos sistemas con lógicas distintas compartan un conjunto acotado de datos con reglas explícitas de quién escribe, cuándo y qué pasa si chocan. El ERP gobierna la realidad administrativa: artículos, precios, pedidos confirmados, albaranes, facturas, cobros. El CRM gobierna la relación comercial: cuentas, contactos, oportunidades, actividades, previsión de ventas.

Lo que no es una integración:

• No es una copia completa de un sistema en el otro. Nadie necesita los 40 campos de un asiento contable dentro del CRM. Se integra lo que se usa para decidir o para trabajar.
• No es un exportador de informes. Si lo único que quieres es ver ventas por comercial, probablemente necesitas un cuadro de mando sobre un almacén de datos, no un conector bidireccional. La diferencia la explicamos en data warehouse para empresa mediana.
• No es un proyecto de IT en exclusiva. El 70 % de las decisiones son de negocio: qué es un cliente activo, qué precio manda si difieren, quién puede cambiar la razón social.

Un buen punto de partida es escribir en una sola página los flujos reales que se piden. En la mayoría de empresas medianas caben cinco o seis: cuenta y datos fiscales, dirección de entrega, catálogo y tarifa, disponibilidad de stock, pedido u oferta, y estado de facturación y cobro. Si tu lista tiene veinte flujos, no tienes un proyecto de integración: tienes una lista de deseos sin priorizar.

¿Quién manda sobre cada dato? La fuente de verdad

Esta es la decisión que determina si el proyecto sale bien. Para cada entidad compartida hay que fijar un sistema maestro —el único que puede crear y modificar— y uno o varios sistemas lectores. Sin esto, dos usuarios editan el mismo cliente en sitios distintos y gana el último que sincronizó, que casi nunca es el que tenía razón.

| Dato | Maestro habitual | Quién lee | Por qué | |---|---|---|---| | Cuenta y datos fiscales (NIF, razón social) | ERP | CRM | Es lo que factura y lo que audita Hacienda | | Prospecto sin NIF | CRM | — | Aún no existe para administración; no ensucia el ERP | | Contactos y actividad comercial | CRM | ERP (solo consulta) | El ERP no necesita saber quién comió con quién | | Catálogo y tarifas | ERP | CRM | El precio oficial es el que se factura | | Descuento excepcional | CRM con aprobación | ERP | Nace en la negociación, se valida antes de pasar | | Stock disponible | ERP | CRM | Dato vivo; se consulta, no se copia | | Oferta / presupuesto | CRM | ERP al ganar | El ERP solo recibe lo que se convierte en pedido | | Pedido confirmado | ERP | CRM | Desde que hay compromiso, manda administración | | Factura y estado de cobro | ERP | CRM | El comercial necesita verlo, no tocarlo |

Dos reglas que ahorran discusiones. Primera: el maestro se define por entidad, no por sistema; es normal que el CRM mande en unas cosas y el ERP en otras. Segunda: el campo que no tiene dueño no se integra. Si nadie se hace responsable de mantener el sector de actividad del cliente, integrarlo solo propaga basura más rápido.

Una integración no arregla un dato maestro sucio: lo replica a más sitios y a más velocidad. Limpiar antes de conectar no es perfeccionismo, es evitar pagar dos veces.

Si tu maestro de clientes tiene duplicados, razones sociales con erratas y NIFs vacíos, el orden correcto es el de gobierno del dato primero y conector después. Una deduplicación previa cuesta semanas; deshacer una duplicación propagada en dos sistemas vivos cuesta meses.

¿Qué patrón de integración conviene en cada caso?

No hay un patrón mejor: hay uno proporcionado al volumen, a la criticidad y al equipo que lo va a mantener.

| Patrón | Cómo funciona | Cuándo encaja | Riesgo principal | |---|---|---|---| | Fichero programado (CSV/SFTP) | Volcados nocturnos entre sistemas | Volúmenes bajos, datos poco críticos, sistemas antiguos sin API | Errores silenciosos: nadie mira el log hasta que falta medio día de pedidos | | Punto a punto por API | Un sistema llama directamente al otro | Dos sistemas, pocos flujos, equipo técnico disponible | Se multiplica: con cinco sistemas tienes veinte conexiones que mantener | | Conector estándar del fabricante | Módulo ya construido para ese par de productos | Cuando existe y cubre tus flujos sin retoques | Se rompe al personalizar el ERP; la versión marca el ritmo | | Plataforma de integración (iPaaS) | Un intermediario con conectores, colas y reintentos | Tres o más sistemas, necesidad de trazabilidad y reproceso | Coste recurrente y dependencia de un proveedor más | | Eventos y cola de mensajes | Cada cambio publica un evento que otros consumen | Alto volumen, necesidad de tiempo casi real, equipo maduro | Complejidad operativa: requiere monitorización de verdad | | Capa de datos intermedia | Todo aterriza en un almacén común y desde ahí se distribuye | Cuando además hay analítica y varios consumidores | Latencia; no sirve para consultar stock en vivo |

Una decisión práctica que se olvida: no todo tiene que sincronizarse igual. El stock se consulta en vivo (el comercial pregunta y el ERP responde en el momento); el catálogo se replica una vez al día; el pedido se envía como evento en cuanto se gana. Mezclar frecuencias no es una chapuza, es diseño: copiar el stock cada noche produce promesas de entrega falsas a media mañana.

¿Cómo se despliega sin parar el negocio?

La secuencia que menos disgustos da tiene cinco fases y no se salta ninguna.

1. Inventario y limpieza (2-4 semanas). Cuántas cuentas hay en cada sistema, cuántas casan por NIF, cuántas están duplicadas. Aquí se decide la clave de correspondencia: NIF cuando existe, un identificador propio cuando no. Nunca el nombre, que cambia y se escribe de cinco maneras. 2. Mapa de campos y reglas. Campo a campo: origen, destino, transformación, qué hacer si el destino tiene valor distinto, qué hacer si el registro no existe. Es un documento tedioso de dos o tres páginas que evita el 80 % de las incidencias posteriores. 3. Sincronización inicial en un entorno de pruebas. Con datos reales copiados. El objetivo no es que funcione: es contar cuántos registros fallan y por qué. Un 5 % de rechazos aquí es normal y manejable; un 30 % significa que la fase 1 no se hizo bien. 4. Puesta en marcha por flujos, no de golpe. Primero lectura (el CRM ve facturas y stock, no escribe nada). Cuando eso lleva dos semanas estable, se abre la escritura del flujo de más valor, normalmente el pedido. Un flujo cada vez. 5. Operación y vigilancia. Un panel con registros procesados, rechazados y pendientes, y una alerta a una persona concreta cuando algo se atasca. Sin esto, la integración se degrada en silencio hasta que alguien la descubre por una reclamación de cliente.

Un detalle que parece menor y no lo es: decide desde el principio qué pasa con los borrados. Borrar un contacto en el CRM no puede borrar un cliente facturable del ERP. Lo habitual y sensato es que los borrados no se propaguen y se gestionen como marcas de "inactivo".

¿Qué errores cuestan meses?

Los que hemos visto repetirse, con nombre y apellidos:

• Bidireccional por defecto. «Que se sincronice en los dos sentidos por si acaso» es la forma más rápida de crear bucles y sobrescrituras. La mayoría de flujos deben ser de un solo sentido; la bidireccionalidad se justifica campo a campo.
• Casar clientes por nombre. «Transportes García S.L.» y «TRANSPORTES GARCIA SL» son el mismo cliente para una persona y dos registros para un conector. Sin clave estable, el proyecto se convierte en un trabajo manual permanente.
• No definir la zona horaria ni el formato de fechas. Parece anecdótico hasta que los pedidos de última hora aparecen con fecha del día siguiente y descuadran el cierre mensual.
• Integrar el campo libre de observaciones. Es el cajón donde el comercial escribe cualquier cosa. Propagarlo al ERP garantiza que alguien acabe facturando según una nota.
• Olvidar el reproceso. Toda integración falla algún día: cae la red, el ERP está en mantenimiento, un campo obligatorio llega vacío. Lo que distingue a una integración profesional es que los mensajes fallidos se guardan, se corrigen y se reenvían sin intervención en base de datos.
• No contar el coste de mantenimiento. Cada actualización de versión del ERP o del CRM puede romper algo. Presupuestar solo la construcción es el error clásico que describimos en cuánto cuesta un proyecto de IA y que aquí aplica igual.
• Dejar a los usuarios fuera hasta el final. Quien detecta que el flujo está mal diseñado es el administrativo que ve llegar pedidos sin dirección de entrega. Si lo ve en la semana 3 y no en la 20, el arreglo es barato.

¿Y dónde encaja aquí la IA?

Después, no antes, y en sitios muy concretos. La integración es fontanería: reglas deterministas, trazables y auditables. Meter un modelo probabilístico en medio del flujo de facturación es buscarse un problema. Dicho esto, hay tres puntos donde aporta de verdad:

• Deduplicación y casado de registros. Decidir si dos cuentas con nombre y dirección parecidos son la misma. Aquí los modelos de similitud aciertan mucho más que una regla fija, siempre con revisión humana de los casos dudosos.
• Normalización de datos sucios. Direcciones, provincias, nombres de contacto, cargos. Convertir el texto libre heredado en campos estructurados antes de la carga inicial.
• Entrada de documentos al flujo. Pedidos que llegan por correo en PDF y alguien teclea en el ERP. Ese es el hueco natural de la automatización de procesos, con validación humana mientras la tasa de error no sea aceptable.

El orden importa: primero datos limpios y sistemas conectados, luego automatización, luego modelos. Es exactamente la secuencia que defendemos en estrategia de datos, y el motivo por el que tantos proyectos de IA se bloquean en la capa de abajo, la de ingeniería de datos.

Preguntas frecuentes

¿Cuánto tarda una integración ERP CRM?

Con los flujos acotados a cinco o seis y los datos maestros razonablemente limpios, entre 6 y 12 semanas hasta el primer flujo en producción. Lo que alarga los plazos casi nunca es el desarrollo: es la limpieza previa de clientes y el tiempo que tarda la empresa en decidir quién manda sobre cada dato.

¿Es mejor un conector estándar o desarrollo a medida?

Si existe un conector del fabricante que cubre tus flujos sin personalizaciones, empieza por ahí: mantenimiento incluido y menos riesgo. En cuanto necesites tres o cuatro excepciones propias, el conector se convierte en un desarrollo a medida disfrazado y con menos margen de maniobra.

¿Hay que sincronizar en tiempo real?

Casi nunca todo. El stock y la disponibilidad se consultan en vivo, los pedidos se envían en cuanto se confirman y el resto puede ir por lotes diarios. El tiempo real multiplica el coste de infraestructura y de vigilancia, así que se reserva para los datos en los que un retraso de horas tiene consecuencias comerciales.

¿Qué pasa si más adelante cambiamos de CRM o de ERP?

Depende del patrón. Con integraciones punto a punto, cambiar un sistema obliga a rehacer todas sus conexiones. Con una plataforma intermedia o una capa de datos común, sustituyes un extremo y mantienes el resto: cuesta algo más al principio y mucho menos el día del cambio.

Si estás en el punto de decidir —o ya tienes dos sistemas peleándose por el mismo cliente—, lo útil no es un comparador de conectores, sino media hora mirando tus datos reales: cuántas cuentas duplicadas hay, qué flujos se usan de verdad y qué decisiones de negocio están sin tomar. Eso es lo que hacemos en la auditoría, y si prefieres contarlo antes en voz alta, hablemos y te decimos con franqueza si tu caso necesita un proyecto o solo dos reglas bien puestas.