Diseñar el ciclo de vida del cliente entre CRM y ERP.
Una arquitectura basada en premisas para una empresa B2B global ficticia: de la intención comercial a un cliente legalmente válido y operativamente recuperable.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01El resultado
La integración no es la arquitectura.
Una empresa B2B global quiere que el CRM «cree clientes en el ERP». La frase esconde tres identidades distintas, dos fronteras de aprobación y un estado de fallo que puede interrumpir los ingresos.
Convertir una intención comercial aprobada en un cliente legal al que se le pueda vender, sin duplicar la identidad ni hacer depender a los usuarios de la disponibilidad del ERP.
Usar un comando asíncrono e idempotente, con estados explícitos de pendiente y de intervención en el CRM.
El ERP controla el alta legal. El CRM posee el ciclo de vida comercial. La capa de integración posee el estado de entrega, no la verdad de negocio.
02Premisas y restricciones
Explicitar qué debe ser cierto antes de elegir.
La recomendación solo es válida para este conjunto de premisas. Si cambian las premisas, la respuesta debe poder cambiar.
- 01Operación global
Varias filiales comparten cuentas comerciales, pero operan a través de registros de cliente legal distintos.
- 02Control financiero
La validación del ERP es obligatoria antes de un pedido; puede rechazar datos fiscales, de crédito o de sociedad.
- 03Disponibilidad variable
El ERP tiene paradas de mantenimiento planificadas y tiempos de respuesta no deterministas entre regiones.
- 04Responsabilidad humana
Un aprobador comercial confirma que todo está listo; operaciones es responsable de las excepciones de integración sin resolver.
«El cliente es del ERP.»
El ERP posee la identidad legal y transaccional del cliente. El CRM puede seguir poseyendo la identidad del prospecto, el contexto de la relación y el estado comercial. La autoridad es una matriz, no un trofeo que se entrega a un sistema.
03La segunda capa
Lo que «crear cliente» deja sin decir.
- P01
¿Qué existe antes del ID del ERP?
- P02
¿Pueden dos filiales compartir una parte pero no un número de cliente?
- P03
¿Un timeout significa fallo o un resultado desconocido?
- P04
¿Quién puede editar los datos fiscales tras el alta?
- P05
¿Qué bloquea el primer pedido mientras el estado está pendiente?
- P06
¿Cómo reenvía soporte sin crear un duplicado?
- P07
¿Qué ve el comercial cuando el ERP no está disponible?
- P08
¿Qué evento hace que la analítica cuente un cliente activo?
04Identidad y fronteras
Una empresa. Tres identidades útiles.
Cuenta
Relación, pipeline e intención. Se crea pronto; autoridad del CRM.
Parte
Organización registrada e identidad fiscal. Se valida antes de operar.
Cliente
Contexto de sociedad, área de ventas y pago. Autoridad del ERP.
Pasa el cursor o el foco por un sistema para ver qué posee, qué no y en qué flujos participa.
05Arquitecturas candidatas
Tres diseños pueden funcionar. Solo uno encaja con estas premisas.
| Espera del usuario | Bloqueado por el ERP | La aprobación termina | La aprobación termina |
|---|---|---|---|
| Recuperación ante fallos | El usuario reintenta | Reenvío gestionado | Siguiente batch |
| Consistencia | Inmediata | Eventual y visible | Diferida |
| Carga operativa | Baja al principio | Responsable explícito de la cola | Intensiva en conciliación |
| Encaja mejor con | Dependencia estable y rápida | Operación global variable | Poca urgencia, volumen |
Latencia variable entre regiones y un proceso que puede continuar mientras se completa el alta legal.
- El CRM debe mostrar Pendiente, Creado y Requiere intervención como estados reales.
- Soporte es responsable de una cola de reenvío con códigos de motivo.
- La entrada de pedidos queda bloqueada hasta tener el número canónico del ERP.
La opción asíncrona no es «más moderna» por sí misma. Encaja porque la aprobación de negocio debe seguir siendo ágil mientras el alta legal es recuperable y observable de forma independiente.
06Diseño recomendado
Confirmar la intención. Conciliar el resultado.
- 01Aprobación comercial
- 02Comando de alta
- 03Validación en el ERP
- 04Evento de resultado
- 05Listo para pedir
- Congelar los datos del alta.
Al aprobar, el CRM crea una instantánea inmutable de la petición y una clave de idempotencia acotada a la entidad jurídica.
- Aceptar; no fingir que ha terminado.
La frontera de integración confirma la recepción duradera. El CRM pasa a
Creation pending: nada de falsos éxitos. - Resolver los resultados inciertos.
Antes de reintentar tras un timeout, consultar el ERP por la clave externa de la petición. Un éxito tardío nunca debe convertirse en un duplicado.
- Publicar un resultado legible para el negocio.
El éxito lleva los identificadores canónicos. El rechazo lleva códigos de motivo estables y un responsable de la reparación, no una traza de error.
07Semántica de fallos
Diseñar la ruta de recuperación antes que la ruta feliz.
Nunca pedir a un usuario que resuelva el resultado incierto de un sistema distribuido pulsando otra vez «Crear».
08Modelo operativo
El modelo de soporte forma parte del diseño.
Responsable de que el proceso esté listo, de la política de aprobación y de la comunicación con los comerciales.
Responsable de las reglas de validación legal, la resolución de duplicados y los atributos transaccionales.
Responsable de la salud del transporte, los controles de reenvío, la correlación y la telemetría de nivel de servicio.
Observar el estado del negocio, no solo la infraestructura.
- Peticiones pendientes más allá de la latencia regional esperada
- Tasa de rechazo por motivo de negocio estable
- Resultados desconocidos a la espera de conciliación
- Antigüedad de las intervenciones manuales y equipo responsable
- Candidatos a duplicado y tiempo de resolución
09Cuándo decidiría distinto
La arquitectura debe moverse cuando se mueve el contexto.
Si el ERP ofrece un alta determinista, idempotente y de alta disponibilidad, y los usuarios no pueden avanzar de forma útil sin su resultado inmediato.
Si el alta no tiene urgencia operativa en el mismo día, los volúmenes son altos y el negocio ya trabaja en ventanas controladas de datos maestros.
Si un servicio corporativo de datos maestros pasa a ser el emisor gobernado de la identidad de la parte para el CRM y el ERP.
No modelar la disponibilidad de un sistema como verdad de negocio. Modelar por separado la intención, el avance y el resultado.Crear el cliente en el ERP de forma asíncronaSeparar la identidad comercial de la identidad legal del clienteVariación regional controlada, oportunidades con varias modalidades comerciales, identidad del cliente, acceso y visibilidadGranularidad e inteligencia comercial, writeback de KPI, conciliación de la segmentación, evolución multidivisa