Separar la identidad comercial de la identidad legal del cliente
Una cuenta es una relación comercial; una entidad legal es una organización registrada; un cliente del ERP es esa entidad en una de nuestras sociedades. Modelar tres identidades vinculadas, no un registro que signifique todo a la vez.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01Contexto
Una empresa B2B global mantiene prospectos, entidades legales, filiales y puntos de entrega en una sola lista de cuentas del CRM, mientras cada ERP numera los clientes por su cuenta. Las integraciones asignan una cuenta del CRM a un cliente del ERP, y eso se rompe en cuanto un grupo compra a través de varias entidades legales o a varias filiales de la propia empresa.
02Factores de decisión
- F01
Los prospectos existen mucho antes de la validación legal
- F02
Una entidad legal puede ser cliente de varias de nuestras sociedades
- F03
Vender y reportar a nivel de grupo
- F04
Las fusiones de registros no deben dejar historial huérfano
03Opciones consideradas
Un registro para todos los significados
Clientes de una sola entidad y un único ERP
Coste: Toda relación multientidad se convierte en un workaroundEl cliente del ERP como cuenta del CRM
Negocios transaccionales con poca prospección
Coste: No hay sitio para prospectos ni relaciones de grupo; el CRM replica la estructura del ERPTres identidades vinculadas
Grupos, varias entidades legales, varios ERP
Coste: Requiere una tabla de correspondencias y reglas de fusión gobernadas04Decisión
Modelar la cuenta comercial (referencia: CRM), la entidad legal con un ID de parte canónico (referencia: datos maestros) y el cliente del ERP por sociedad (referencia: ERP) como identidades separadas y vinculadas. La capa de integración es responsable de la tabla de correspondencias; ningún sistema reconstruye la identidad a partir de nombres.
05Consecuencias
- Una cuenta comercial puede vincularse a varias entidades legales, y cada entidad legal a varios clientes del ERP.
- Las comprobaciones de duplicados se hacen sobre claves naturales antes de crear, no después.
- Una fusión conserva el ID superviviente, traslada el historial y mantiene los ID retirados resolubles como alias.
- Los informes consolidan por cuenta comercial o por entidad legal sin contradecirse.
06Cuándo revisarla
Un servicio corporativo de datos maestros emite la identidad de parte para todos los sistemas.
El negocio se consolida en un único ERP y una única entidad legal por cliente.
07Dónde se aplica esta decisión
Casos que adoptan esta decisión, y por qué importa en cada uno.
- Caso de arquitectura / 001Diseñar el ciclo de vida del cliente entre CRM y ERPUna arquitectura basada en premisas para una empresa B2B global ficticia: de la intención comercial a un cliente legalmente válido y operativamente recuperable.
- Caso de sistemas / 05La identidad del cliente entre CRM y ERPSeparar la identidad comercial, la legal y la transaccional, y gobernar cómo se mapean, se fusionan y se retiran entre el CRM y el ERP.
- Caso de datos / 02Convertir transacciones del ERP y objetivos en inteligencia comercialConformar pedidos, facturas, objetivos y cuentas a una granularidad declarada en la plataforma de datos, para que una única definición de métrica sirva a todos los equipos y su resultado llegue al CRM como señal gobernada.
- Caso de automatización / 04Validación y asignación automáticas de leads entrantesLa perspectiva de la ejecución sobre los leads entrantes: un circuito de asignación en el que cada comprobación tiene un resultado determinista y un camino declarado para cuando hay dudas, que puede repetirse sin riesgo y con las asignaciones fallidas a la vista.
- Caso de IA / 05IA para la calidad de datos sin darle autoridad sobre los datos maestrosUn agente sugiere candidatos a duplicado, nombres normalizados y clasificaciones que faltan—con evidencia—en la cola de un data steward. Nunca fusiona, renombra ni reclasifica un registro por sí mismo.
- Caso de modelo operativo / 04Diseñar la responsabilidad sobre el cliente en una organización con varias filialesUna relación con un cliente que abarca varias entidades legales, filiales y equipos de ventas: quién es responsable de la relación, de cada transacción local y de los datos globales de la cuenta—y quién resuelve los conflictos.