Diseñar los límites entre sistemas detrás de una plataforma comercial global
Un caso ficticio y compuesto: la dirección pidió «una única plataforma comercial». El trabajo consistía en decidir para qué sirve cada plataforma que la forma, y en qué no debe convertirse.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
El caso en síntesis
Realidad actual
Todo el mundo habla de «una única plataforma comercial», pero en ella participan una web, un CRM, una capa de integración, varios ERP y una plataforma de datos; sin fronteras explícitas, cada requisito nuevo acaba derivando hacia el CRM.
Qué tiene que llegar a ser cierto
Los usuarios trabajan en un entorno comercial coherente, mientras cada plataforma tiene un rol claro, responsabilidades y no-responsabilidades explícitas, los conceptos sobre los que tiene autoridad, interfaces declaradas y una razón para formar parte de la arquitectura.
Pregunta de diseño
¿Qué capacidad comercial corresponde a cada plataforma, y qué fronteras no deberían borrarse solo para que la experiencia parezca unificada?
01La realidad · situación actual
Cómo es hoy la plataforma.
Un fabricante B2B global ficticio vende a través de sus propias filiales, de distribuidores y de un canal digital en crecimiento. En cada momento comercial participan varias plataformas: los formularios web y los portales captan la demanda, el CRM gestiona la relación, una capa de integración mueve peticiones y resultados, el ERP de cada filial ejecuta pedidos y facturas, y una plataforma de datos conserva el histórico. Hasta ahora, cada proyecto resolvió su necesidad añadiendo datos o lógica al CRM, porque es allí donde están los usuarios.
- Los datos de clientes, productos, precios, stock y pedidos se copian en el CRM «para que los usuarios lo vean todo»
- El estado de un pedido puede cambiarse en dos sitios, y nadie sabe cuál es el correcto
- Los contadores de reintentos y los estados de error se guardan como campos del CRM que los comerciales pueden editar
- El análisis histórico se hace con informes del CRM que nunca se diseñaron para guardar histórico
- Pasos de la ejecución de pedidos se reconstruyen como automatizaciones del CRM, junto a los controles del propio ERP
- Cada petición nueva pregunta «¿puede hacerlo el CRM?» en lugar de «¿dónde debe vivir esto?»
02El problema de frontera
Qué está mezclado hoy.
El CRM se estaba convirtiendo poco a poco en cuatro sistemas a la vez. Cada petición era razonable por sí sola; juntas, borraron las fronteras.
- Un ERP parcialPrecios, stock y estados de pedido copiados y editados en el CRM, cada vez más alejados de la verdad transaccional.
- Un almacén de datos parcialAños de transacciones cargados para informes que el CRM nunca estuvo pensado para ejecutar.
- Un motor de flujos de trabajoPasos de la ejecución de pedidos reconstruidos como automatizaciones del CRM, duplicando controles que el ERP ya aplica.
- Un hub de integraciónContadores de reintentos, copias de mensajes y estados de error guardados en registros de negocio.
03Dimensión clave · Capacidad → responsabilidad de plataforma
Una capacidad, un responsable, y roles secundarios declarados
La matriz parte de las capacidades de negocio, no de los productos. Para cada una: dónde se crea su verdad, dónde se hace el trabajo, quién orquesta, quién solo consume y qué no debe moverse.
| Capacidad de negocio | Digital | CRM | Integración | ERP | Datos | Lo que no debe moverse |
|---|---|---|---|---|---|---|
| Relación con el cliente | Consume | Posee | Sin rol | Consume | Consume | El cliente del ERP es una identidad legal, no la relación. |
| Lead y oportunidad | Actúa | Posee | Sin rol | Sin rol | Deriva | Los portales captan la demanda; la cualificación se queda en el CRM. |
| Actividades y planificación comercial | Sin rol | Posee | Sin rol | Sin rol | Deriva | Los planes viven donde los comerciales actúan sobre ellos. |
| Ofertas y propuestas | Consume | Posee | Orquesta | Consume | Sin rol | Una oferta es una propuesta; solo se convierte en pedido en el ERP. |
| Condiciones de precio | Consume | Consume | Sin rol | Posee | Deriva | El CRM lee el precio que necesita una oferta; nunca mantiene condiciones. |
| Producto y stock | Consume | Consume | Sin rol | Posee | Deriva | La disponibilidad se muestra a los comerciales, no se guarda como verdad del CRM. |
| Ejecución de pedidos y facturación | Consume | Consume | Orquesta | Posee | Deriva | El estado es visible en el CRM y nunca se edita allí. |
| Cliente legal y transaccional | Sin rol | Consume | Orquesta | Posee | Consume | Lo emite el ERP tras la validación; el CRM guarda una referencia. |
| Estado de entrega de la integración | Sin rol | Consume | Posee | Consume | Sin rol | Se muestra a los usuarios como un estado, nunca como un campo de negocio. |
| Histórico y señales de rendimiento | Sin rol | Consume | Sin rol | Consume | Posee | El CRM recibe señales, no años de transacciones. |
- Posee
- Donde se crea y se modifica su verdad
- Actúa
- Donde se hace parte del trabajo
- Orquesta
- La mueve entre plataformas
- Consume
- La usa sin modificarla
- Deriva
- Calcula algo nuevo a partir de ella
Una experiencia de usuario unificada no exige que un solo sistema sea responsable de todo.
Plataforma comercial B2B global05Diseño de interacciones
Qué cruza una frontera, cuándo y por qué.
Lo que cruza cada frontera es un estado de negocio con una identidad y un responsable, no una API que llama a otra.
| Evento de negocio | Identidad | Estado | Quién conserva la autoridad | Momento |
|---|---|---|---|---|
| Se envía una consultaCruza: Digital → CRM | ID del envío y candidatos de coincidencia de parte | Consulta recibida; todavía no es un lead | El CRM decide si es un lead; el portal solo confirma la recepción | Asíncrono: el visitante recibe un acuse de recibo, no una decisión |
| Una oferta necesita un precioCruza: CRM → ERP (lectura) | Artículo y referencia de cliente del ERP | Una propuesta de precio para esta oferta | El ERP conserva la autoridad; la oferta registra el precio usado y cuándo | Bajo demanda, al preparar la oferta |
| Una operación ganada se convierte en pedidoCruza: CRM → integración → ERP | ID de oportunidad, número de cliente del ERP, ID de correlación | Comprometida comercialmente; pedido solicitado | El ERP decide si el pedido existe; el CRM continúa cuando llega el resultado | Comando asíncrono con un estado pendiente explícito |
| Un pedido se envía o se facturaCruza: ERP → integración → CRM | Número de pedido y número de cliente del ERP | Resumen del estado del pedido | Solo lectura en el CRM | Un evento cada vez que cambia el estado |
| El histórico se convierte en una señalCruza: ERP → plataforma de datos → CRM | Cuenta comercial y periodo | Una señal derivada: tendencia, brecha o riesgo | La plataforma de datos la deriva; el CRM actúa sobre ella | Se publica por periodo |
06Fallos y recuperación
Rechazado, tardío, incierto o no disponible.
Cada frontera necesita una respuesta diseñada ante el rechazo, el retraso y la incertidumbre; si no, el CRM acaba absorbiendo el apaño.
| Situación | Respuesta diseñada | Quién lo repara | Cómo se detecta |
|---|---|---|---|
| El ERP rechaza una petición de pedido | La oportunidad sigue ganada; la petición muestra un código de motivo y vuelve a su responsable comercial | Responsable comercial, con gestión de pedidos | Un evento de rechazo con un código de motivo estable |
| No llega ninguna respuesta | Se trata como desconocido, no como fallido: se consulta el ERP por el ID de correlación antes de cualquier reintento | Soporte de integración | Pendiente más allá de su ventana esperada |
| La lectura del precio no está disponible | La oferta puede prepararse pero no emitirse; se muestra el último precio usado con su fecha | El comercial y, después, el equipo de precios | Una lectura fallida al preparar la oferta |
| Una copia se desvía de su origen | La reconciliación compara referencias y estados; gana el origen y la diferencia queda registrada | Responsable de la plataforma CRM | Una ejecución de reconciliación programada |
07Arquitecturas candidatas
Opciones creíbles, evaluadas frente a estas premisas.
Hacer del CRM el único sistema comercial
Operaciones pequeñas de una sola entidad
Coste: El CRM se convierte a la vez en un ERP, un almacén de datos y un hub parciales; cada cambio es arriesgadoDejar que cada proyecto decida dónde viven sus datos
Entregas locales rápidas
Coste: Verdad duplicada y acoplamiento punto a puntoUna plataforma responsable por capacidad y una experiencia única a través de interfaces declaradas
Un entorno con varias entidades y varios ERP
Coste: Requiere un mapa de capacidades, contratos de interfaz y un responsable de las fronterasDecisión de diseño
Asignar a cada capacidad comercial una única plataforma responsable —aquella donde se crea su verdad—, dejar que el CRM presente el resto y actúe sobre él mediante interfaces declaradas, y mantener la capa de integración como responsable de la entrega, nunca de la verdad de negocio.
08Arquitectura resultante
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.
Web y portalesCRMCapa de integraciónERPPlataforma de datos
Web y portales
Donde entra la demanda- Captar consultas y solicitudes
- Vistas de autoservicio para clientes y partners
- El consentimiento en el momento de la captación
- Las decisiones de cualificación
- La identidad del cliente tras la validación
- Precios más allá de los publicados
CRM
Donde se gestiona la relación comercial- El estado de la relación, los leads y las oportunidades
- Actividades, planes y aprobaciones comerciales
- La oferta como propuesta comercial
- Presentar el contexto operativo a los comerciales
- Condiciones de precio y stock
- Ejecución de pedidos y facturación
- El estado de entrega de las integraciones
- La analítica histórica
Capa de integración
Cómo cruza el estado una frontera- El estado de entrega de cada petición
- El mapeo entre modelos
- Correlación, reenvío y ejecuciones de reconciliación
- Ninguna decisión de negocio
- La verdad de los registros que mueve
ERP
Donde se ejecutan las transacciones- El cliente legal y transaccional
- Maestro de artículos, condiciones de precio y stock
- Pedidos, entregas y facturas
- El pipeline comercial
- El contexto de la relación
Plataforma de datos
Donde el histórico se convierte en señales- Histórico armonizado entre sistemas
- Señales comerciales y KPI derivados
- Decisiones operativas
- Editar ningún registro de origen
09Gobierno y operación
Quién responde de la frontera a lo largo del tiempo.
Las fronteras se erosionan petición a petición, salvo que alguien responda de ellas.
| Qué | Responsable | Cadencia | Evidencia |
|---|---|---|---|
| El mapa de responsabilidad sobre las capacidades | Comité de arquitectura de plataforma | Con cada petición que movería una capacidad | Peticiones que piden a una plataforma asumir un rol nuevo |
| Contratos de interfaz | Responsable de integración | Versionados en cada cambio | Cambios de contrato y los consumidores a los que afectan |
| Copias guardadas en el CRM | Responsable de la plataforma CRM | Trimestral | Dominios replicados, su volumen y su uso |
10La segunda capa
Preguntas que cambian la arquitectura.
Responsabilidad
- ¿Dónde se crea esta verdad, y dónde solo se cambia por accidente?
- ¿Necesita el CRM el dato o una representación útil de él?
- ¿Quién es responsable de la definición de cada concepto?
Experiencia
- ¿Qué vistas deben parecer unificadas al usuario?
- ¿Qué fronteras deben seguir siendo visibles, incluso en una sola pantalla?
- ¿Qué ve el usuario mientras otro sistema decide?
Cambio
- ¿Qué petición movería una capacidad, y quién la aprueba?
- ¿Qué debe seguir siendo transaccional y qué corresponde a la analítica?
- ¿Dónde vive la orquestación?
11Decisiones y entregables
Qué produce el trabajo.
- 01Mapa de responsabilidad sobre las capacidades
- 02Declaración del rol de cada plataforma
- 03No-responsabilidades por plataforma
- 04Catálogo de interfaces
- 05Proceso de revisión de fronteras
- 06Arquitectura de referencia