La identidad del cliente entre CRM y ERP
Un caso ficticio sobre identidad: qué representa una cuenta, cómo se corresponden las cuentas comerciales con entidades jurídicas y números de cliente del ERP, y qué sobrevive a una fusión.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01El resultado
Tres identidades explícitas —comercial, legal y transaccional— enlazadas por una identidad de negocio canónica, con reglas gobernadas para buscar coincidencias, fusionar y retirar.
Prospectos, filiales, varios números de cliente del ERP y duplicados conviven bajo una misma palabra: «cuenta».
¿Qué representa una cuenta, y quién emite la identidad en la que todos los sistemas pueden confiar?
Separar la identidad comercial (la cuenta del CRM) de la identidad legal y transaccional (parte y números de cliente del ERP), enlazadas mediante un ID de parte canónico emitido por una única autoridad.
Una empresa B2B global vende a grupos con muchas entidades jurídicas y puntos de entrega, a través de varias filiales propias, cada una con un ERP que numera los clientes de forma independiente. El CRM mantiene prospectos y clientes en una misma lista de cuentas. Aparecen duplicados, las fusiones rompen el histórico y nadie sabe decir si una «cuenta» es un grupo, una entidad jurídica o una dirección de entrega.
02La realidad · situación actual
Cómo es hoy la plataforma.
- «Cuenta» significa un grupo para unos equipos, una entidad jurídica para otros y una dirección para unos pocos
- La misma entidad jurídica tiene varios números de cliente en el ERP
- Se crean duplicados porque la búsqueda de coincidencias se hace después del alta
- Las fusiones en el CRM dejan referencias del ERP y oportunidades apuntando a ninguna parte
- Las integraciones mapean IDs uno a uno y se rompen cuando la relación es de uno a muchos
- El rendimiento a nivel de grupo es invisible porque las jerarquías están incompletas
03Responsabilidades de sistema
Cada plataforma, una función y una frontera.
Qué posee cada plataforma en este diseño y qué deliberadamente no. Son las responsabilidades para este contexto, no reglas universales.
CRM
Identidad comercial- Cuenta comercial y contexto de la relación
- Jerarquía de venta (grupo → unidades de compra)
- Comprobación de duplicados antes del alta
- Solicitudes de fusión de registros comerciales
- Datos de la entidad jurídica tras la validación
- Numeración de clientes del ERP
Capa de integración
Correlación de identidades- Tabla de correspondencias entre IDs del CRM, de parte y del ERP
- IDs de correlación en cada mensaje
- Propagación de fusiones y retiradas
- Decidir si dos registros son la misma entidad
ERP
Identidad legal y transaccional- Validación de la entidad jurídica (parte)
- Números de cliente por sociedad
- Atributos de facturación, pago y fiscales
- Prospectos
- La jerarquía de venta
Plataforma de datos
La visión a nivel de grupo- Rendimiento consolidado a través de la jerarquía
- Analítica de candidatos a duplicado
- Decisiones de identidad o fusiones
04Dimensión clave · Identidad y jerarquía
Cuatro niveles, tres identidades
La integración se vuelve frágil cuando la identidad se trata como «mapear el ID y listo». Cada nivel tiene su propia clave, su propia autoridad y su propia cardinalidad.
- Cuenta comercialLa relación a la que vendemos
- Clave
- ID de cuenta del CRM
- Autoridad
- CRM
- Cardinalidad
- Una por relación comercial
- Entidad jurídicaLa organización registrada que firma y paga
- Clave
- ID de parte canónico
- Autoridad
- Datos maestros en el ERP
- Cardinalidad
- Una o varias por cuenta comercial
- Cliente del ERPEsa entidad jurídica como cliente de una de nuestras sociedades
- Clave
- Número de cliente del ERP
- Autoridad
- Cada ERP
- Cardinalidad
- Uno por entidad jurídica y sociedad
- UbicaciónDonde se entregan los productos o se envían las facturas
- Clave
- ID de dirección
- Autoridad
- ERP, tras la validación
- Cardinalidad
- Varias por cliente del ERP
- Buscar antes de crear
Los candidatos a duplicado se comprueban sobre claves naturales —número de registro, NIF, nombre normalizado y país— antes de que exista ningún registro.
- Un emisor por identificador
El ID de parte canónico tiene exactamente un emisor. Los demás sistemas lo guardan como referencia y nunca lo generan.
- La fusión conserva el histórico
El registro superviviente conserva su ID; oportunidades, actividades y correspondencias pasan a él; el ID retirado se mantiene como alias.
- Retirar, no borrar
Las identidades retiradas siguen siendo resolubles, de modo que pedidos, facturas e informes históricos siguen apuntando a algún sitio.
- Correlacionar cada mensaje
Cada petición entre sistemas lleva un ID de correlación y el ID canónico, para asociar los resultados sin adivinar.
- La jerarquía no es identidad
Los vínculos matriz–filial describen cómo vendemos y reportamos. Nunca fusionan dos entidades jurídicas.
La mayoría de los defectos de integración en este ámbito son, en realidad, defectos de identidad.
06Arquitecturas candidatas
Opciones creíbles, evaluadas frente a estas premisas.
Una cuenta equivale a un cliente del ERP
Clientes de una sola entidad y un único ERP
Coste: Se rompe en cuanto un cliente compra a dos de nuestras sociedadesEl CRM emite el ID canónico
El CRM es el primer y único sistema que ve todas las partes
Coste: Se mezclan prospectos y entidades jurídicas; el ERP debe fiarse de datos no validadosCuenta comercial en el CRM, ID de parte canónico desde datos maestros y correspondencias en la integración
Grupos, varias entidades jurídicas, varios ERP
Coste: Requiere una tabla de correspondencias y un proceso de fusión gobernado07La segunda capa
Preguntas que cambian la arquitectura.
Significado
- ¿Qué representa una cuenta: entidad jurídica, relación, ubicación o grupo?
- ¿Cuándo deben varios clientes del ERP corresponder a una misma cuenta, y cuándo no?
- ¿Un prospecto es el mismo registro que el cliente en que se convierte?
Autoridad
- ¿Quién emite la identidad canónica?
- ¿Quién puede fusionar dos cuentas y quién decide que son la misma?
- ¿Cómo se detectan los candidatos a duplicado, y cuándo?
Histórico
- ¿Qué sobrevive a una fusión?
- ¿Qué ocurre con las oportunidades y los pedidos históricos?
- ¿Cómo se sigue resolviendo una identidad retirada?
08Decisiones y entregables
Qué produce el trabajo.
- 01Modelo de identidad
- 02Modelo de jerarquías
- 03Reglas de duplicados y claves naturales
- 04Política de fusión y retirada
- 05Registro de claves entre sistemas
- 06Medidas de calidad de la identidad