Diseñar la visibilidad de producto, precios, stock y transacciones sin convertir el CRM en un ERP
Un caso ficticio y compuesto: los comerciales necesitan tener delante productos, precios, stock, pedidos y facturas. El trabajo consistía en decidir cuánto del ERP debe contener realmente el CRM.
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
Los comerciales necesitan contexto operativo de los ERP —productos, precios, stock, pedidos abiertos, facturas—, y la respuesta por defecto ha sido «sincronizarlo todo en el CRM».
Qué tiene que llegar a ser cierto
Los comerciales ven suficiente contexto de producto, precio, disponibilidad y transacciones para tomar decisiones comerciales —con la frescura que cada decisión necesita de verdad—, mientras la verdad de productos, precios, stock, pedidos y facturas se queda en los sistemas construidos para ejecutarlos.
Pregunta de diseño
¿Qué información del ERP debe poseer, replicar, resumir o derivar el CRM, y cuál debe limitarse a referenciar?
01La realidad · situación actual
Cómo es hoy la plataforma.
Un fabricante B2B ficticio vende un catálogo amplio a través de varias filiales, cada una con su propio ERP, sus almacenes y sus condiciones de precio. Los comerciales preparan ofertas, visitan clientes y hacen seguimiento de pedidos en el CRM, pero las respuestas que necesitan —qué se puede vender, a qué precio, si está disponible, qué tiene abierto el cliente o qué debe— viven en los ERP. Hasta ahora, cada petición de visibilidad se ha resuelto copiando otra tabla en el CRM.
- El CRM guarda una copia completa del maestro de artículos, aunque la mayor parte nunca llega a ofertarse
- Los precios copiados por la noche ya son erróneos por la tarde, así que los comerciales llaman al back office para confirmarlos
- El stock aparece como un único número, aunque la disponibilidad depende del almacén y de la sociedad vendedora
- Las líneas de pedido y las facturas se replican completas: el volumen del ERP sin sus controles
- Los usuarios editan campos copiados y la siguiente carga los sobrescribe sin avisar
- Nadie sabe decir qué copia usó un informe ni lo antigua que era
02El problema de frontera
Qué está mezclado hoy.
«Ver» y «poseer» se trataban como la misma petición. Cada vez que un comercial necesitaba ver algo, el CRM acababa guardándolo.
- Ver frente a poseerUn precio mostrado en una oferta se convirtió en un precio mantenido en el CRM.
- Producto comercial frente a artículo del ERPUn producto comercial corresponde a varios artículos, centros y variantes; la copia daba por hecho una relación uno a uno.
- Estado actual frente a históricoLos comerciales necesitaban saber qué está abierto ahora; la copia trajo años de líneas.
- Dato frente a señalUn cliente en declive es una señal derivada de las transacciones, no un motivo para cargar todas las facturas.
03Dimensión clave · Visibilidad sin autoridad
Dónde vive cada dominio y qué hace el CRM con él
Cada fila responde a las mismas preguntas: qué sistema puede cambiarlo, qué necesita realmente el comercial, cómo llega al CRM, lo actualizado que debe estar y qué decisión cambia.
| Dominio | Sistema con autoridad | Qué necesita el CRM | Modo de interacción | Frescura necesaria | Por qué lo necesita el comercial |
|---|---|---|---|---|---|
| Producto | Maestro de artículos del ERP; la estructura comercial se mantiene para vender | Los productos comerciales vendibles y su estructura, no cada artículo, centro y variante | Subconjunto replicadoUn subconjunto filtrado de lo que se puede ofertar | Diaria; los cambios son escasos y planificados | ¿Qué puedo ofrecer a este cliente? |
| Precios | Condiciones de precio del ERP por sociedad vendedora y canal | El precio para este cliente, artículo y cantidad al ofertar, y el precio usado, registrado en la oferta | Lectura bajo demandaSe lee al preparar la oferta | En el momento de ofertar | ¿Con qué precio me comprometo? |
| Stock y disponibilidad | ERP, por almacén y sociedad vendedora | La disponibilidad para el lugar de entrega del cliente, no un total global | Lectura bajo demandaSe consulta cuando se pregunta y nunca se guarda | Actual, en el momento de preguntar | ¿Puedo comprometer una fecha? |
| Pedidos | ERP | Los pedidos abiertos y su estado por cuenta | Subconjunto replicadoUn resumen de solo lectura, actualizado por eventos de estado | Dentro de la hora siguiente a un cambio | ¿Qué tiene abierto el cliente, y qué va con retraso? |
| Facturas | ERP: la verdad financiera | Un indicador de vencidas y un enlace al documento | ReferenciadoSe referencia y se abre en el origen | Indicador diario; documento bajo demanda | ¿Hay algún problema de pago antes de la visita? |
| Señales comerciales | Plataforma de datos, derivadas del histórico del ERP | Tendencia, brecha y riesgo por cuenta y periodo | Señal derivadaUna señal publicada con su versión de definición | Por periodo | ¿A qué debo dedicar mi tiempo? |
La visibilidad no es autoridad. No hay que llevar una transacción al CRM cuando basta con una señal comercial gobernada.
05Diseño de interacciones
Qué cruza una frontera, cuándo y por qué.
Cada lectura y cada evento se diseñan en torno a la decisión a la que sirven, y a lo que ve el comercial cuando la respuesta no llega.
| Evento de negocio | Identidad | Estado | Quién conserva la autoridad | Momento |
|---|---|---|---|---|
| Un comercial pone precio a una línea de ofertaCruza: CRM → integración → ERP (lectura) | Producto comercial → artículo del ERP, número de cliente del ERP, sociedad vendedora | Precio para este cliente, artículo y cantidad | El ERP conserva la autoridad; la oferta guarda el precio usado y una marca de tiempo | Lectura síncrona con un timeout corto |
| Un comercial pregunta si se puede servirCruza: CRM → integración → ERP (lectura) | Artículo del ERP y lugar de entrega del cliente | Disponibilidad y fecha más temprana | Solo lectura; no se guarda nada en el CRM | Bajo demanda |
| Un pedido cambia de estadoCruza: ERP → integración → CRM | Número de pedido y número de cliente del ERP | Resumen de estado (confirmado, retrasado, enviado, facturado) | El CRM lo muestra y no puede editarlo | Un evento en cada cambio |
| Se cierra un periodoCruza: ERP → plataforma de datos → CRM | Cuenta comercial y periodo | Señales: tendencia, brecha frente al objetivo, riesgo | La plataforma de datos las deriva con una versión de definición | Se publican por periodo |
06Fallos y recuperación
Rechazado, tardío, incierto o no disponible.
Una visibilidad que falla en silencio es peor que no tener visibilidad: el comercial siempre debe saber qué está mirando.
| Situación | Respuesta diseñada | Quién lo repara | Cómo se detecta |
|---|---|---|---|
| La lectura del precio agota el tiempo de espera | La línea conserva su último precio, marcado con su fecha, y la oferta no puede emitirse hasta confirmarlo | El comercial, con soporte de precios | Timeout al preparar la oferta |
| No se puede leer la disponibilidad | El comercial ve «disponibilidad desconocida», nunca un número desfasado | Soporte de integración | Lectura fallida o lenta |
| Se pierde un evento de estado | Una reconciliación periódica compara los pedidos abiertos y restaura el resumen; gana el ERP | Responsable de la plataforma CRM | Ejecución de reconciliación |
| Un producto comercial no tiene un artículo válido para una sociedad | No se ofrece para esa sociedad; el hueco de mapeo pasa a gestión de producto | Gestión de producto | Comprobación del mapeo al publicar |
07Arquitecturas candidatas
Opciones creíbles, evaluadas frente a estas premisas.
Replicarlo todo en el CRM
Un catálogo pequeño y un solo ERP
Coste: Copias desfasadas, volumen, verdad duplicada, usuarios editando copiasNo mostrar nada y enviar a los comerciales al ERP
Ventas dirigidas desde el back office
Coste: Los comerciales pierden contexto; aparecen hojas de cálculo paralelasUbicación por dominio: un pequeño subconjunto replicado, datos bajo demanda, resúmenes de solo lectura y señales derivadas
Varios ERP, un catálogo amplio, venta de campo
Coste: Requiere contratos de lectura, estados «desconocido» explícitos y un responsable de la ubicaciónDecisión de diseño
Decidir la ubicación dominio a dominio, a partir del propósito, la autoridad, la granularidad, la frescura y el volumen: replicar solo un subconjunto comercial pequeño y estable; leer bajo demanda los datos volátiles en el momento de decidir; mostrar las transacciones como resúmenes de solo lectura que enlazan con el origen; y sustituir el histórico de transacciones por señales gobernadas.
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.
CRMCapa de integraciónERPPlataforma de datos
CRM
Donde se toman las decisiones comerciales- La oferta y el precio con el que se comprometió
- La estructura de producto comercial que ofrecen los comerciales
- Presentar resúmenes, estados y señales
- Condiciones de precio
- Stock y disponibilidad
- La verdad de pedidos, entregas y facturas
Capa de integración
Lecturas y eventos a través de la frontera- Contratos de lectura bajo demanda (precio, disponibilidad)
- Eventos de estado de los pedidos
- Reglas de caché y timeouts de las lecturas
- Los valores que devuelve
- Lo que decide el comercial
ERP
Verdad transaccional por sociedad vendedora- Maestro de artículos y datos de centro
- Condiciones de precio por canal y cliente
- Stock por almacén
- Pedidos, entregas y facturas
- La vista de producto comercial
- Las señales comerciales
Plataforma de datos
El histórico convertido en señales- Histórico de transacciones con una granularidad armonizada
- Señales por cuenta y periodo, con su versión de definición
- Los valores operativos sobre los que actúa el comercial al ofertar
09Gobierno y operación
Quién responde de la frontera a lo largo del tiempo.
La ubicación es una decisión que tiene que sobrevivir a la próxima petición de «añadir solo un campo».
| Qué | Responsable | Cadencia | Evidencia |
|---|---|---|---|
| La matriz de ubicación | Responsable de la plataforma CRM, con los responsables de los ERP | Con cada petición de visibilidad | Peticiones para replicar un dominio o un campo nuevo |
| Mapeo de producto a artículo | Gestión de producto | En cada publicación del catálogo | Productos comerciales sin un artículo válido por sociedad |
| Definiciones de señales | Responsable de la plataforma de datos | Versionadas en cada cambio | Señales consumidas en el CRM y su versión de definición |
10La segunda capa
Preguntas que cambian la arquitectura.
Propósito
- ¿Qué decisión comercial cambia porque esto sea visible?
- ¿Necesita el comercial el histórico, o solo el estado actual o una señal?
- ¿Quién actúa sobre ello, y cuándo?
Autoridad y granularidad
- ¿Qué sistema puede cambiarlo?
- ¿Qué significa un registro, y un producto comercial corresponde a un artículo o a varios?
- ¿Depende el valor del almacén, de la sociedad o del canal?
Frescura y coste
- ¿Cómo de actual debe ser realmente en el momento de decidir?
- ¿Qué cuesta copiarlo en volumen, acoplamiento y desviación?
- ¿Qué ve el comercial cuando el origen no responde?
11Decisiones y entregables
Qué produce el trabajo.
- 01Matriz de ubicación de la información
- 02Requisito de frescura por decisión
- 03Reglas de mapeo de producto a artículo
- 04Contratos de lectura de precio y disponibilidad
- 05Definiciones de señales comerciales
- 06Revisión de la replicación