Cómo integrar ERP, CRM y el proceso de ventas

Conectar el ERP con el CRM parece un problema de credenciales y termina siendo un problema de decisiones. Estas son las que hay que tomar antes de escribir código, y los fallos que aparecen cuando alguna se salta.

Primero: quién manda sobre cada dato

Si el ERP y el CRM pueden editar el mismo campo, tarde o temprano habrá dos valores distintos y alguien tendrá que decidir cuál gana. Esa decisión se toma por CAMPO, no por sistema: el precio puede ser del ERP y el estado del negocio del CRM.

Segundo: en qué dirección viaja cada cosa

Una sincronización en un sentido es sensiblemente más simple y suele bastar. La bidireccional exige resolver conflictos y duplica la superficie de error. Conviene empezar en un sentido y ampliar si el proceso lo pide de verdad.

El inventario mínimo antes de empezar

• Qué sistemas intervienen, en qué versión y qué forma de acceso ofrecen (API, base de datos, archivos).
• Quién es dueño de cada dato y quién decide cuando dos sistemas no coinciden.
• El volumen aproximado: registros por día y picos conocidos, como un cierre de mes.
• Qué pasa hoy cuando un dato no cuadra y quién lo corrige.
• Si existen entornos de prueba y credenciales separadas para ellos.

El flujo, paso a paso

• Un registro cambia en el sistema de origen y se emite un evento o se detecta en una consulta periódica.
• Se transforma al formato del destino, decidiendo qué hacer con los campos que el destino no admite.
• Se escribe con una clave de idempotencia estable entre ambos sistemas.
• Se registra el resultado. Si falla, se reintenta con espera creciente.
• Al agotar los intentos, el registro va a una cola de revisión, nunca al vacío.

Los cuatro fallos que aparecen siempre

• Duplicados por reintento. Sin clave de idempotencia, cada reintento crea un registro nuevo. Se descubre al cierre de mes, cuando los totales no cuadran.
• Silencio. Sin registro de ejecuciones ni alertas, el error lo descubre un cliente. Un flujo que falla en silencio es peor que no tenerlo.
• Cambios de API sin dueño. El proveedor actualiza y nadie sabe si le toca arreglarlo. Se resuelve por contrato, no por buena voluntad.
• Datos históricos inconsistentes. Lo que más retrasa un proyecto no es el código: es descubrir que un campo significa tres cosas distintas según el año.

Cómo se prueba antes de encenderla

En un entorno de prueba y con fallos provocados a propósito: credenciales vencidas, un campo obligatorio vacío, el mismo registro enviado dos veces y el sistema de destino caído. Si la integración resiste esos cuatro casos, resiste el día a día. La carga de datos históricos se hace aparte, por lotes pequeños y con conteos que se puedan cuadrar.

Qué deberías recibir al terminar

• El mapeo de campos documentado, con el dueño de cada uno.
• El registro de ejecuciones y las alertas, con a quién avisan.
• El procedimiento para reprocesar un registro desde la cola de revisión.
• El responsable acordado cuando un proveedor cambie su API.

Cómo saber si hace falta código o basta una plataforma

Una plataforma de automatización resuelve bien flujos de volumen moderado con conectores existentes. Conviene código propio cuando el volumen, las reglas de transformación o los requisitos de auditoría superan lo que la plataforma soporta. La tecnología se elige después del alcance, nunca antes. Si buscas quién lo haga, este es nuestro servicio de integración de sistemas.