Arquitectura de Sistemas y CRM
Diseñar la plataforma comercial antes de configurar el CRM.
Traduzco los ciclos de vida del negocio en responsabilidades de sistema: decido qué posee el CRM, qué posee el ERP, dónde reside la autoridad sobre los datos, cómo viajan las identidades y cómo evolucionan las plataformas sin acoplarse en exceso.
El mismo ciclo de vida comercial en cuatro plataformas. Elige una para ver qué posee y cuándo cambia de manos la autoridad.
| 01Decisión: Lead | 02Acción humana: Prospecto | 03Acción humana: Oportunidad | 04Punto de aprobación: Aprobación | 05Acción de sistema: Cliente | 06Acción de sistema: Pedido | |
|---|---|---|---|---|---|---|
| CRM | Registro y asignación del lead — responsable | Cuenta de prospecto — responsable | Oportunidad y oferta — responsable | Registro de aprobación — responsable | Muestra «alta pendiente» — apoya | Estado del pedido, solo lectura — apoya |
| Integración | No interviene | Búsqueda de la parte — apoya | No interviene | No interviene | Comando de alta · estado de entrega — responsable | Eventos de pedido y factura — apoya |
| ERP | No interviene | Índice de partes, solo lectura — apoya | No interviene | No interviene | Cliente legal y número (cambio de autoridad) — responsable | Pedido, entrega y factura — responsable |
| Plataforma de datos | Histórico de origen — apoya | No interviene | Histórico del pipeline — apoya | No interviene | Eventos del ciclo de vida — apoya | Ingresos y rendimiento — responsable |
| Autoridad sobre el cliente | CRM — responsable | CRM — responsable | CRM — responsable | CRM — responsable | ERP (cambio de autoridad) — responsable | ERP — responsable |
01LeadRegistro y asignación del lead
- CRM
- Registro y asignación del lead — responsable
- Integración
- No interviene
- ERP
- No interviene
- Plataforma de datos
- Histórico de origen — apoya
- Autoridad sobre el cliente
- CRM — responsable
02ProspectoCuenta de prospecto · Índice de partes, solo lectura
- CRM
- Cuenta de prospecto — responsable
- Integración
- Búsqueda de la parte — apoya
- ERP
- Índice de partes, solo lectura — apoya
- Plataforma de datos
- No interviene
- Autoridad sobre el cliente
- CRM — responsable
03OportunidadOportunidad y oferta
- CRM
- Oportunidad y oferta — responsable
- Integración
- No interviene
- ERP
- No interviene
- Plataforma de datos
- Histórico del pipeline — apoya
- Autoridad sobre el cliente
- CRM — responsable
04AprobaciónRegistro de aprobación
- CRM
- Registro de aprobación — responsable
- Integración
- No interviene
- ERP
- No interviene
- Plataforma de datos
- No interviene
- Autoridad sobre el cliente
- CRM — responsable
05ClienteMuestra «alta pendiente» · Cliente legal y número
- CRM
- Muestra «alta pendiente» — apoya
- Integración
- Comando de alta · estado de entrega — responsable
- ERP
- Cliente legal y número — responsable
- Plataforma de datos
- Eventos del ciclo de vida — apoya
- Autoridad sobre el cliente
- ERP — responsable
06PedidoEstado del pedido, solo lectura · Pedido, entrega y factura
- CRM
- Estado del pedido, solo lectura — apoya
- Integración
- Eventos de pedido y factura — apoya
- ERP
- Pedido, entrega y factura — responsable
- Plataforma de datos
- Ingresos y rendimiento — responsable
- Autoridad sobre el cliente
- ERP — responsable
No es configurar un CRM. Son las responsabilidades detrás de las plataformas.
La arquitectura de sistemas decide para qué sirve cada plataforma antes de que nadie decida cómo configurarla: qué capacidad soporta, qué conceptos posee y dónde está su frontera.
Decidir qué objeto del CRM crearAñadir campos hasta que el requisito encajeConectar aplicaciones porque contienen datos relacionadosDar por hecho que el CRM debe poseer todos los conceptos comerciales
- CapacidadesDefinir lo que el negocio debe ser capaz de hacer.
- Estados del ciclo de vidaDefinir los estados de negocio y qué los hace cambiar.
- Fronteras de sistemaDecidir qué hace cada plataforma y qué no.
- ResponsabilidadAsignar un único responsable a cada capacidad y concepto.
- IdentidadDefinir cómo una entidad sigue siendo la misma entre sistemas.
- Contratos de integraciónDiseñar qué cruza una frontera y con qué garantías.
- VariaciónDecidir qué puede diferir por región y dónde reside.
- AccesoDiseñar quién puede ver, crear y modificar qué.
- Comportamiento ante fallosDefinir qué ocurre cuando un sistema va lento, se equivoca o no está disponible.
- EvoluciónDiseñar qué puede cambiar sin cambiarlo todo.
- CRM«Maestro de clientes»
- ERP«Maestro de clientes»
- E-commerce«Maestro de clientes»
- Plataforma de datos«Maestro de clientes»
Cuatro maestros, un cliente: cada cambio se convierte en una conciliación.
- Estado comercialCRM
- Número legal de clienteERP
- Dirección de facturación (tras el alta)ERP
- Cuenta web y preferenciasE-commerce
- Rendimiento del clientePlataforma de datos
La autoridad es una matriz, no un trofeo que se entrega a un sistema.
Si todos los sistemas poseen al cliente, ningún sistema posee al cliente.
Una frontera de plataforma es tan importante como una capacidad de plataforma.
La mayoría de los problemas de arquitectura aparecen cuando dos sistemas creen, a la vez, que son la referencia.
De la capacidad de negocio a la arquitectura de plataforma.
Nueve movimientos que convierten un ciclo de vida de negocio en responsabilidades de sistema. Cada uno produce un entregable del que depende el siguiente—y la configuración llega después de todos ellos.
01Partir de la capacidad de negocio
¿Qué necesita poder hacer el negocio?
Definir capacidades antes que tecnologías.
- Gestionar un prospecto
- Cualificar una oportunidad
- Aprobar condiciones comerciales
- Crear un cliente legal
- Procesar un pedido
- Medir el rendimiento de una cuenta
Una capacidad sin responsable se convierte en una funcionalidad que cada sistema implementa a medias
Partir de la capacidad de negocio
¿Qué necesita poder hacer el negocio?
Definir capacidades antes que tecnologías.
- Gestionar un prospecto
- Cualificar una oportunidad
- Aprobar condiciones comerciales
- Crear un cliente legal
- Procesar un pedido
- Medir el rendimiento de una cuenta
Mapa de capacidadesUna capacidad sin responsable se convierte en una funcionalidad que cada sistema implementa a medias
Definir el ciclo de vida
¿Qué estados de negocio existen, y qué los cambia?
Los estados describen el negocio, no una pantalla.
- Estado
- Transición
- Disparador
- Responsable
- Representación en el sistema
Modelo de ciclo de vida y estadosUn mismo estado puede representarse de forma distinta en dos sistemas—siempre que su significado sea compartido
Asignar la responsabilidad de cada sistema
¿Qué plataforma debe ejecutar cada capacidad?
Una capacidad, una plataforma que la ejecuta—aunque varias lean el resultado.
- CRM
- ERP
- Capa de integración
- Plataforma de datos
- Servicios externos
- Proceso humano
Mapa capacidad–sistema«Ambos» rara vez es una respuesta; suele ser un futuro problema de conciliación
Definir la autoridad del dato
¿Quién puede crear y modificar cada concepto de negocio?
La autoridad corresponde a conceptos y campos, no a registros completos.
- CRM: estado comercial
- ERP: número legal de cliente
- Plataforma de datos: medidas analíticas derivadas
Matriz de autoridad del datoLa autoridad puede moverse con el ciclo de vida: una propuesta en el CRM se convierte en un hecho validado en el ERP
Definir la identidad
¿Cómo sigue siendo la misma una entidad de negocio en todos los sistemas?
La identidad no es un mapeo de campos.
- IDs externos
- IDs canónicos
- Claves naturales
- Reglas de duplicados
- Comportamiento de fusión
- Transferencia de identidad
Modelo de identidadLa mayoría de los defectos de integración son defectos de identidad disfrazados
Diseñar las fronteras de plataforma
¿Qué no debe hacer deliberadamente cada plataforma?
Una frontera importa tanto como una capacidad.
- Fronteras de responsabilidad
- Capacidades duplicadas
- Responsabilidad en la sombra
- Acoplamientos prohibidos
Mapa de responsabilidades de sistemaSi dos sistemas creen ser la referencia, la conciliación se convierte en un trabajo permanente
Diseñar acceso y gobierno
¿Quién puede ver, crear y modificar qué?
El acceso es arquitectura, no una tarea administrativa de última hora.
- Visibilidad de registros
- Acceso organizativo
- Responsabilidad
- Jerarquía
- Delegación
- Campos sensibles
- Gobierno
Modelo de acceso y gobiernoLa responsabilidad es rendición de cuentas; la visibilidad es una decisión de diseño aparte
Diseñar interfaces y fallos
¿Cómo colaboran los sistemas cuando algo sale mal?
Diseñar el resultado desconocido antes que el camino feliz.
- Síncrono o asíncrono
- Estado de entrega
- Reintentos
- Idempotencia
- Conciliación
- Observabilidad
- Consistencia eventual
Modelo de contratos de integraciónUn timeout no es un fallo; es un resultado desconocido
Diseñar para evolucionar
¿Qué puede cambiar de forma independiente?
Cada acoplamiento es una futura dependencia entre releases.
- Configuración o código
- Global o local
- Fronteras de capacidad
- Versionado
- Responsable de cada release
- Dependencias del roadmap
Roadmap de evolución de la arquitecturaUn roadmap organizado solo por proyectos oculta qué capacidades están acopladas
Los síntomas llegan como peticiones de configuración.
«Añade un campo.» «Sincronízalo en ambos sentidos.» «Dales su propio tipo de registro.» Debajo, hay una responsabilidad que nunca se asignó.
El CRM y el ERP modifican los mismos atributos del cliente.
Lo que suele faltarAutoridad sobre los datos a nivel de campoLos estados del ciclo de vida existen en varios sistemas, con significados distintos.
Lo que suele faltarUna única definición del ciclo de vida, representada en cada sistemaLos equipos siguen creando registros de cliente duplicados.
Lo que suele faltarReglas de identidad: buscar antes de crearLas etapas de la oportunidad reflejan la configuración, no la forma en que vende el negocio.
Lo que suele faltarUn modelo de oportunidad que distinga las modalidades comercialesLas reglas de acceso crecieron de forma orgánica; nadie sabe explicar quién ve qué.
Lo que suele faltarUn modelo de acceso explícitoLa variación regional se implementa con bifurcaciones y excepciones.
Lo que suele faltarPuntos de configuración declaradosLas integraciones dependen de las estructuras internas de otro sistema.
Lo que suele faltarContratos de integración establesEl CRM se ha convertido en una base de datos de reporting, con analítica dentro de los flujos transaccionales.
Lo que suele faltarUna frontera entre sistemas operativos y analíticos
Entregables con los que un equipo de plataforma puede construir, gobernar y evolucionar.
Cada uno resuelve una pregunta que, de otro modo, la configuración respondería por accidente.
- Mapa de capacidades¿Qué debe ser capaz de hacer el negocio, con independencia de las herramientas?
- Modelo de dominio del CRM¿Qué conceptos comerciales existen y cómo se relacionan?
- Modelo del ciclo de vida del cliente¿Qué estados de negocio existen y qué los hace cambiar?
- Modelo de cuentas y relaciones¿Qué representa una cuenta y cómo se relacionan las cuentas entre sí?
- Arquitectura de oportunidades¿Qué modalidades comerciales comparten ciclo de vida y cuáles necesitan el suyo propio?
- Mapa de responsabilidades de sistema¿Qué posee cada plataforma y qué deliberadamente no?
- Matriz de fuentes de referencia¿Quién puede crear, modificar, leer o derivar cada concepto?
- Modelo de identidad¿Cómo sigue siendo la misma una entidad entre sistemas?
- Modelo de acceso y visibilidad¿Quién puede ver, crear y modificar qué?
- Topología de integración¿Qué sistemas intercambian qué, cómo y con qué garantías?
- Modelo de variación global/local¿Qué es núcleo, qué es configurable y qué es una extensión local?
- Registros de decisión de arquitectura¿Qué decisiones se tomaron y sobre qué premisas?
- Hoja de ruta de la plataforma¿Qué cambia y cuándo, y qué puede cambiar de forma independiente?
Empezar por las capacidades. Después, asignar a cada una su plataforma.
Una capacidad de negocio es lo que la organización debe ser capaz de hacer. Un sistema es una forma de implementarla, y algunas capacidades corresponden a una persona, no a una plataforma.
Gestionar una oportunidad comercial
implementada por CRM
Aprobar condiciones comerciales
implementada por CRMLa decide una persona; se registra en el CRM
Dar de alta un cliente legal
implementada por ERP
Emitir una factura
implementada por ERP
Encaminar una integración fallida
implementada por Capa de integración
Calcular el rendimiento histórico del cliente
implementada por Plataforma de datos
Comprobar datos registrales y de sanciones
implementada por Servicio externo
Decidir el crédito por encima de un umbral
implementada por Proceso humanoSe registra en el ERP
Qué posee cada plataforma y qué no
CRM
Espacio de trabajo comercial- Ciclo de vida comercial
- Interacción comercial
- Estado de trabajo
- Contexto de la relación
- Identidad legal del cliente
- Facturas y estado financiero
- Histórico analítico
Capa de integración
Entrega, no verdad de negocio- Transporte
- Estado de entrega
- Idempotencia
- Reintentos
- Correlación
- Reglas de negocio
- Datos de clientes o pedidos
- Decidir resultados
ERP
Verdad legal y financiera- Cliente legal
- Cliente transaccional
- Pedidos
- Facturación
- Estado financiero
- Prospectos y pipeline
- Contexto de la relación
- Actividad comercial
Plataforma de datos
Histórico y señales derivadas- Histórico analítico
- Medidas derivadas
- Señales entre sistemas
- Escrituras operativas
- Flujo transaccional
- Ediciones a nivel de registro
- CRM → hacia Capa de integración: Comandos
- Capa de integración → hacia ERP: Alta · modificación
- ERP → hacia Capa de integración: Resultados · eventos
- Capa de integración → hacia CRM: Estado
- CRM · ERP → hacia Plataforma de datos: Eventos · hechos
- Plataforma de datos → hacia CRM: Señales, solo lectura
Ejemplos para un contexto B2B global, no verdades universales. En otro negocio el ERP puede poseer los precios, o el CRM puede no contener nunca un pedido: lo importante es que cada responsabilidad se asigna de forma deliberada.
Nueve conceptos y quién posee cada parte de ellos.
Selecciona un concepto para ver qué representa, qué sistema posee cada uno de sus aspectos, de dónde procede y qué depende de él. No todos los conceptos pertenecen de forma nativa al CRM.
Cuenta
La relación comercial
- Responsable comercial
- CRM
- Identidad legal
- ERP
- Rendimiento analítico
- Plataforma de datos
- Ciclo de vida
- Prospecto → cliente → inactiva
- Procedencia
- El CRM durante la prospección; los datos legales, del ERP tras el alta
- Relaciones
- Lead se convierte en Cuenta · Cuenta tiene Contacto · Cuenta tiene Oportunidad
- Dependientes
- ContactosOportunidadesPedidosFacturasReporting
Una cuenta, tres autoridades: eso es el diseño, no un conflicto.
Un cliente, tres identidades.
La relación comercial, la entidad jurídica registrada y el cliente en cada ERP son cosas distintas, con emisores distintos. La arquitectura de identidad las mantiene enlazadas sin fingir que son una sola.
- ID de cuenta del CRMIdentidad comercial: la relación a la que vendemosLo emite el CRMEnlace 1 → 1…n
- Identidad de negocio canónicaLa entidad jurídica registrada, un único ID de parteLo emiten una vez los datos maestrosEnlace 1 → 1…n
- ID(s) de cliente del ERPEsa entidad jurídica como cliente de cada una de nuestras sociedadesLo emite cada ERP
01Identificadores canónicos
Un emisor por identificador. Los demás sistemas lo guardan como referencia y nunca lo generan.
02Identificadores propios de cada sistema
Cada sistema conserva su propio ID; la tabla de correspondencias los enlaza. Nadie reconstruye la identidad a partir de nombres.
03Claves naturales
Número de registro, NIF, nombre normalizado y país: sirven para encontrar candidatos, nunca como clave primaria.
04Candidatos a duplicado
Se comprueban antes del alta. Un candidato es una pregunta para una persona, no una fusión automática.
05Fusión
El registro superviviente conserva su ID; el histórico y las correspondencias pasan a él; el ID retirado se mantiene como alias.
06Retirada
Las identidades retiradas siguen siendo resolubles, de modo que los pedidos y los informes históricos siguen apuntando a algún sitio.
07IDs de correlación
Cada petición entre sistemas lleva uno, para asociar cada resultado a su petición sin adivinar.
08Matriz–filial
Las jerarquías describen cómo vendemos y reportamos. Un vínculo de matriz nunca fusiona dos entidades jurídicas.
ADR 005 · Separar la identidad comercial de la identidad legal del cliente
Aislar la variación en lugar de bifurcar la plataforma.
Las regiones difieren por motivos legales, fiscales y operativos. La pregunta de diseño no es si pueden diferir, sino qué capa absorbe cada diferencia y quién es su responsable.
- Núcleo global
Igual en todas partes; solo cambia a través del gobierno global
- Ciclo de vida común
- Conceptos de datos canónicos
- Semántica de reporting compartida
- Variación configurable
Varía mediante configuración declarada, dentro de límites globales
- Umbrales de aprobación
- Reglas de asignación
- Roles locales
- Validaciones seleccionadas
- Extensión local
Solo donde las restricciones legales, fiscales o del ERP no se pueden configurar
- Campos legales propios de un país
- Un mapeo a un ERP local
- Documentos de salida locales
Cada paso hacia la derecha tiene un coste: se prueba, se documenta y se actualiza por separado. Una extensión local necesita un motivo que la configuración no pueda cubrir, y un responsable y una fecha de revisión en el registro de variaciones.
ADR 006 · Representar la variación regional mediante configuración, no con bifurcaciones del CRM
Quién puede ver, crear y modificar qué es una decisión de diseño.
Los modelos de acceso que crecen excepción a excepción acaban siendo inexplicables. Los diseñados derivan la visibilidad de la responsabilidad, los equipos y la jerarquía, y mantienen el permiso de edición deliberadamente más restringido.
| Anillo | Quién | Ver | Editar |
|---|---|---|---|
| Responsable | Un gestor de cuenta, responsable último | Total | Total |
| Equipo de cuenta | Especialistas y responsables de cuentas globales | Total | Sus propias aportaciones |
| Jerarquía | Mandos por encima del responsable | Total | Ninguno por defecto |
| Región y global | Roles regionales y globales | Resumen | Ninguno |
- Responsabilidad Rendir cuentas, no ver.
- Visibilidad Se deriva de los equipos y la jerarquía; no se concede a mano.
- Permiso de edición Más restringido que el de lectura, por diseño.
- Datos sensibles Las condiciones de crédito y el margen tienen su propia frontera.
- Compartición Las excepciones manuales llevan responsable y fecha de caducidad.
Seis preguntas de plataforma, seis respuestas de arquitectura.
Escenarios sintéticos de empresas B2B globales, construidos a partir de patrones recurrentes. Cada uno se abre en su propia página con responsabilidades de sistema, autoridad sobre los datos, opciones y compromisos, y las preguntas que cambian el diseño.
- Caso 01Caso seleccionadoProceso → frontera de sistema → identidad → estado
Diseñar el ciclo de vida del cliente entre CRM y ERP
«El CRM debería crear clientes en el ERP» esconde tres identidades, dos fronteras de aprobación y un estado de fallo que puede interrumpir los ingresos.
¿Cuándo deja el CRM de ser el responsable del cliente, y qué ve el usuario mientras decide el ERP?
CRMCapa de integraciónERPDatos e IntegracionesArquitectura de Procesos - Caso 02Arquitectura de referenciaResponsabilidad sobre las capacidades en toda la plataforma
Plataforma comercial B2B global
Un entorno comercial con múltiples sistemas en el que nadie sabe decir qué plataforma posee cada capacidad.
¿Qué plataforma posee cada capacidad, y dónde se encuentran los sistemas operativos y los analíticos?
WebCRMIntegraciónERPPlataforma de datosDatos e IntegracionesRevenue Operations - Caso 03Núcleo global frente a variación configurable
Un CRM global sin bifurcar el modelo operativo
Las filiales necesitan reglas realmente distintas, y hasta ahora cada diferencia ha acabado en una copia de la configuración.
¿Qué pertenece al núcleo global, qué es configurable y qué no debe bifurcarse nunca?
CRM globalCapa de integraciónERP localesPlataforma de datosModelo Operativo DigitalDatos e Integraciones - Caso 04Núcleo común + modalidad especializada
Un solo CRM para varias modalidades comerciales
Nuevo negocio, proyectos estratégicos, ampliación de líneas y crecimiento en cuentas se fuerzan a través de un mismo ciclo de vida, o están a punto de separarse en modelos incompatibles.
¿Qué estados son universales, qué etapas cambian y qué significa ‘Closed Won’ en cada modalidad?
CRMPricingERPPlataforma de datosRevenue OperationsArquitectura de Procesos - Caso 05Identidad y jerarquía
La identidad del cliente entre CRM y ERP
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?
CRMCapa de integraciónERPPlataforma de datosDatos e IntegracionesArquitectura de Procesos - Caso 06Responsabilidad, visibilidad y permiso de edición
Visibilidad en el CRM para una organización comercial global
Las reglas de acceso crecieron petición a petición; nadie sabe explicar quién ve qué, ni por qué.
¿Ser responsable significa rendir cuentas o ver, y cómo se concede el acceso sin hacerlo todo público?
CRMDatos de RR. HH. y organizaciónProveedor de identidadPlataforma de datosModelo Operativo DigitalRevenue Operations
Toda petición de configuración tiene una segunda capa.
La petición visible es donde empieza la arquitectura, no donde termina.
“Crea una cuenta.”
Añadir un registro de cuenta con el nombre y la dirección del cliente.
4 de 6 preguntas a la vista
¿Un grupo, una entidad jurídica, una relación o una ubicación? Cada respuesta da lugar a un modelo de datos distinto.
Las fronteras de plataforma dan forma a todas las demás capacidades.
Arquitectura de Sistemas y CRM
- Arquitectura de Procesos
El proceso define el ciclo de vida y las decisiones; la arquitectura de sistemas decide qué plataforma soporta cada una.
- Modelo Operativo Digital
La responsabilidad, el gobierno y las reglas de variación vienen del modelo operativo; la plataforma las codifica.
- Datos e Integraciones
Las decisiones de autoridad e identidad se convierten en contratos de integración, eventos y conciliación.
- Automatización
La automatización se ejecuta dentro de la frontera de una plataforma; la orquestación se diseña donde las fronteras se encuentran.
- Revenue Operations
Los modelos de pipeline, forecast y cuentas son decisiones de arquitectura del CRM con las que RevOps trabaja cada día.
- IA y Flujos Agénticos
Los agentes heredan el modelo de identidad y autoridad: una responsabilidad clara es lo que hace seguras sus acciones.
- Cambio y Adopción
Una plataforma que encaja con la forma de vender se adopta; una que codifica el organigrama se esquiva.
Decisiones de arquitectura
Trabajo relacionado
Un CRM no es la arquitectura. La arquitectura es el conjunto de decisiones que define
- Capacidades
- Ciclos de vida
- Responsabilidades de sistema
- Identidad
- Autoridad sobre los datos
- Acceso
- Integración
- Variación
- Evolución
El CRM es una plataforma que implementa parte de esa arquitectura.
¿Dos sistemas convencidos de que poseen al cliente?
- ¿Qué concepto tiene dos maestros, o ninguno?
- ¿Dónde cambia de manos la autoridad y quién lo ve?
- ¿Qué te obligaría a bifurcar una nueva región?