Integrar CRM y ERP
sin romper nada.

El problema real

Una empresa mediana termina, casi sin darse cuenta, con dos sistemas que hablan del mismo cliente. El CRM lo conoce como prospecto: quién lo atiende, qué se le ofreció, en qué etapa va. El ERP lo conoce como cuenta por cobrar: qué se le facturó, qué pagó, cuánto crédito tiene. Ambos tienen razón dentro de su mundo, y ninguno sabe lo que sabe el otro.

La consecuencia se nota primero en las personas: alguien captura el mismo dato dos veces, ventas promete a un cliente que finanzas tiene bloqueado, y la dirección pide un reporte que exige exportar de ambos lados y cuadrarlo a mano. Integrarlos resuelve eso, pero antes de escribir una línea de código hay cuatro decisiones que definen si la integración va a durar.

Decisión 1: quién es la fuente de verdad de cada dato

No de cada sistema: de cada dato. Es la decisión que más integraciones arruina cuando se salta.

Un reparto que funciona en la mayoría de los casos: el CRM manda en los datos comerciales —contacto, oportunidad, etapa, responsable— y el ERP manda en los financieros y de operación —crédito, facturas, pagos, inventario, precios oficiales. El dato que se comparte, típicamente la identidad del cliente, necesita un dueño único y explícito.

Escríbelo en una tabla de dos columnas antes de empezar: dato y sistema dueño. Si el equipo no logra ponerse de acuerdo en alguna fila, esa fila es donde la integración fallará más adelante, y es mucho más barato discutirla ahora.

Decisión 2: en qué dirección fluye

• Unidireccional — un sistema escribe, el otro sólo lee. Es simple, predecible y suficiente para más casos de los que la gente supone. Empieza aquí siempre que puedas.
• Bidireccional — ambos escriben. Multiplica la complejidad, porque obliga a resolver conflictos: si el mismo campo cambió en los dos lados desde la última sincronización, alguien tiene que decidir cuál gana, y esa regla debe ser explícita, no accidental.

La pregunta que ordena la decisión es sencilla: ¿de verdad necesitas editar este dato en ambos sistemas, o basta con verlo en uno de ellos? Buena parte de los requisitos “bidireccionales” se disuelve al plantearla.

Decisión 3: cómo se reconoce que dos registros son el mismo

Es el detalle aburrido que hunde proyectos. El CRM identifica al cliente por correo; el ERP por RFC o por un código interno. Ninguno de los dos es fiable por sí solo: los correos cambian de dueño, y el mismo RFC ampara a varias sucursales que compran por separado.

Lo que funciona es establecer una llave de correspondencia explícita: cada registro guarda el identificador del otro sistema, y esa relación se crea una sola vez, con supervisión humana en los casos ambiguos. Emparejar por nombre o por similitud parece práctico durante la demostración y produce clientes duplicados en producción.

Antes de conectar nada, conviene además limpiar los duplicados que ya existen. Una integración sobre datos sucios los propaga a los dos lados, y desenredarlo después cuesta más que haberlos limpiado antes.

Decisión 4: cuándo se sincroniza

• Por eventos (casi en tiempo real). Un cambio dispara la sincronización de inmediato. Es lo que la gente imagina y lo correcto cuando el retraso tiene consecuencias — un bloqueo de crédito, por ejemplo.
• Por lotes programados. Cada hora, o cada noche. Más simple de operar, más fácil de reintentar y perfectamente adecuado para catálogos, listas de precios o reportes.

Mezclar ambos por tipo de dato suele ser lo más sensato: eventos para lo urgente, lotes para lo voluminoso. Lo que no conviene es sincronizar todo en tiempo real por costumbre, porque cada flujo instantáneo es un punto de falla que hay que vigilar.

Lo que hay que construir aunque nadie lo pida

• Bitácora de todo lo que cruza. Qué se envió, cuándo, con qué resultado. Sin esto, diagnosticar “este cliente no aparece en el ERP” es adivinar.
• Reintentos con espera creciente. Las APIs fallan de forma temporal. Reintentar de inmediato y sin límite es la forma más rápida de que el proveedor te limite el acceso.
• Operaciones idempotentes. Si el mismo mensaje llega dos veces —y va a pasar—, el resultado debe ser idéntico a recibirlo una vez. De lo contrario aparecen facturas y pedidos duplicados.
• Una alerta que llegue a una persona. Una integración que falla en silencio es peor que no tenerla: el negocio sigue confiando en datos que dejaron de actualizarse.
• Un tablero mínimo. Cuántos registros se sincronizaron hoy, cuántos fallaron, cuál fue el último error. Cinco minutos de consulta para el responsable, en lugar de abrir un ticket.

Un orden de implementación que reduce el riesgo

Empezar por el flujo más valioso y más simple —normalmente crear en el ERP los clientes que nacen en el CRM—, dejarlo correr en paralelo con la captura manual hasta que ambos coincidan durante varios días, y sólo entonces retirar el paso manual y añadir el siguiente flujo.

Cada flujo nuevo se agrega igual: en paralelo, verificado, y sólo después sustituyendo el trabajo humano. Es la diferencia entre una integración que el equipo termina confiando y una que todos revisan a mano “por si acaso” — que es exactamente el trabajo que se quería eliminar.