Integrar CRM y ERP: quién manda sobre cada dato

La respuesta corta: crea una matriz por campo antes de conectar

Para cada campo anota quién lo crea, quién puede editarlo, sistema autoritativo, consumidores, identificador, latencia aceptable, regla de conflicto y responsable de una excepción. Ejemplo: el CRM propone una dirección comercial, pero el ERP confirma la dirección fiscal usada en factura; ninguno debería sobrescribir al otro bajo un nombre genérico como dirección. La matriz revela cuándo hacen falta dos campos con propósitos distintos.

El objetivo no es una réplica perfecta, sino una operación coherente. La automatización de captación y seguimiento de leads cubre el tramo comercial anterior; aquí tratamos el límite entre ventas y gestión. Salesforce clasifica varios patrones de integración y subraya gobierno, mastering y deduplicación. Elegir el mecanismo de intercambio viene después de resolver esos significados.

Asigna autoridad según el significado del campo

Evita decidir por aplicación completa: “el ERP manda” no resuelve el teléfono de un contacto ni el estado comercial; “el CRM manda” no debe alterar un saldo contable. Añade propósito y granularidad. Cliente comercial, cuenta de facturación, persona de contacto y destinatario de envío pueden relacionarse sin ser la misma entidad. Nombra las relaciones para impedir que una actualización legítima en un contexto destruya información válida en otro.

Trata la identidad como un proceso, no como una coincidencia de email

Asigna una clave interna estable y conserva los identificadores de cada sistema. Email, teléfono, NIF o nombre pueden faltar, cambiar, compartirse o contener errores; úsalos como atributos de coincidencia con reglas y revisión, no siempre como clave única. Define alta, posible duplicado, unión, separación y cambio de empresa. Una unión equivocada puede mezclar historial comercial, pedidos y preferencias; una separación tardía puede mantener dos fichas contradictorias.

El patrón de Microsoft para sincronizar datos maestros parte de un entorno autoritativo y utiliza claves alternativas para actualizar sin crear duplicados, además de reconciliación programada. El ejemplo tecnológico no decide tu modelo, pero confirma dos requisitos: una clave compartida estable y un proceso que encuentre diferencias. Documenta quién puede aprobar una unión o corregir un identificador.

Da al consentimiento y las preferencias un dueño operativo

No reduzcas consentimiento, oposición o preferencia de canal a un booleano que cualquier sistema sobrescribe. Define finalidad o categoría, estado, origen, momento, evidencia disponible y quién está autorizado a modificarlo. Decide dónde se registra la instrucción más reciente y cómo se propaga a las herramientas que ejecutan comunicaciones. Este diseño es operativo; la base y las obligaciones aplicables deben validarse por separado para el contexto de la empresa.

Distingue correcciones de identidad de cambios de preferencia. Actualizar un email no debería reactivar una comunicación detenida, y unir dos contactos no debería escoger silenciosamente el valor más permisivo. Define una regla conservadora y una cola de revisión cuando las evidencias no puedan combinarse. Registra el motivo del cambio y permite a operaciones explicar qué sistema lo originó sin exponer más datos de los necesarios.

Especifica conflictos, bajas y correcciones retroactivas

Para cada campo elige una política: rechazar cambios no autorizados, aceptar el dato del sistema autoritativo, conservar ambos como valores con propósitos diferentes o enviar a revisión. “El último cambio gana” falla cuando los relojes difieren, una importación antigua parece nueva o dos campos no significan lo mismo. Muestra las excepciones con contexto y una acción; no obligues a resolverlas directamente en registros técnicos.

Define qué significa eliminar en cada entidad: desactivar, cerrar, anonimizar, desvincular o impedir uso futuro son acciones distintas. Un pedido histórico no debería desaparecer porque se cierre una oportunidad. Si una corrección afecta datos derivados —por ejemplo, un cliente unido por error— enumera qué registros deben recalcularse y cuáles requieren decisión humana. Conserva un rastro proporcionado de la corrección y del responsable.

Opera una reconciliación con responsables y umbrales

Las repeticiones pueden ocurrir aunque el flujo normal sea correcto. El patrón Idempotent Consumer de Microsoft explica por qué una clave estable permite que procesar de nuevo una misma instrucción no duplique el efecto. Mantén este requisito en los criterios, sin convertirlo en la estrategia completa. La reconciliación sigue siendo necesaria para fallos, importaciones y correcciones humanas. Si la matriz descubre procesos todavía sostenidos por hojas, revisa cuándo sustituir Excel por una aplicación. El servicio de automatización con IA puede partir de reglas de autoridad y controles explícitos antes de automatizar intercambios.