Convertir transacciones del ERP y objetivos en inteligencia comercial
Un caso ficticio de arquitectura de datos: granularidad, identidad conformada, hechos que llegan tarde, correcciones y cierre de periodo, antes de construir ningún dashboard.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01El resultado
Un único modelo conformado a nivel de cuenta × línea de producto × mes, con un estado de periodo explícito, a partir del cual cada métrica de rendimiento se calcula una sola vez y se publica en el CRM.
Pedidos, facturas y objetivos llegan de sistemas distintos, con granularidades y tiempos distintos, así que cada informe responde a una pregunta ligeramente diferente.
¿Cuál es la granularidad de cada hecho, y dónde se encuentran sin contar dos veces?
Conformar los hechos en la plataforma de datos a una granularidad compartida y publicar métricas, en lugar de copiar transacciones en el CRM o hacer informes desde cada fuente por separado.
Un fabricante B2B vende a través de varias sociedades propias, cada una con su propio código de sociedad en el ERP. Los equipos comerciales quieren una única vista de pedidos, facturas y objetivos por cliente, filial y periodo. Hoy cada región exporta datos del ERP a hojas de cálculo, los cruza con el CRM por nombre de cliente y calcula sus propias cifras de rendimiento.
02La realidad · situación actual
Qué hacen hoy los datos.
- Las líneas de pedido y de factura se cruzan directamente, así que las entregas parciales se cuentan dos veces
- Los clientes se emparejan por nombre; los grupos que compran a través de varias entidades legales se dividen o se mezclan
- Las facturas llegan un día después que los pedidos, así que cada mañana el rendimiento de ayer parece peor
- Los objetivos fijados a mitad de año se comparan con datos reales de todo el año
- Los pedidos cancelados y los abonos se eliminan o se ignoran según quién haya construido el informe
- Cada región convierte las divisas con su propio tipo de cambio
03Flujo objetivo
De dónde vienen los datos, adónde van… y cómo.
Cada traspaso se nombra con su modo. El modo sigue la tolerancia del negocio a la espera, a la inconsistencia y a la pérdida.
- 01 · ERPPedidos del ERPAlimenta por Batch
Líneas de pedido por sociedad, conservando todas las versiones.
- 02 · ERPFacturas del ERPAlimenta por Batch
Líneas de factura contabilizadas, abonos incluidos.
- 03 · PlanificaciónObjetivosAlimenta por Batch
Versiones publicadas de objetivos por cuenta, línea de producto y mes.
- 04 · CRMCuentas del CRMAlimenta por Evento
Cuentas comerciales, jerarquía y vínculos con entidades legales.
- 05 · Plataforma de datosPlataforma de datosTraspasa por Batch
Hechos conformados y clave analítica de cliente.
- 06 · Plataforma de datosCálculo de métricasTraspasa por Batch
Rendimiento frente a objetivo, cobertura y estado del periodo.
- 07 · CRMActivación en el CRM
Señales de solo lectura en la cuenta, con fecha de referencia.
04Contratos
Qué significa una fila o un mensaje.
Significado, granularidad, clave, frescura y responsable, por escrito antes de mapear nada.
Línea de pedido
Un compromiso comercial; cambia hasta que se entrega o se cancela.
- Granularidad
- Una fila por línea de pedido y versión
- Clave
Sociedad + pedido + línea + versión- Frescura
- Diaria, antes de las 06:00
- Responsable
- Responsable del dato en el ERP
Línea de factura
Una venta reconocida. Se corrige con abonos, nunca se edita.
- Granularidad
- Una fila por línea de factura contabilizada
- Clave
Sociedad + factura + línea- Frescura
- Diaria, antes de las 06:00
- Responsable
- Finanzas
Objetivo
Un plan publicado; los objetivos de año parcial empiezan en su mes de vigencia.
- Granularidad
- Cuenta × línea de producto × mes
- Clave
Versión de objetivo + cuenta + línea + mes- Frescura
- Al publicarse
- Responsable
- Operaciones de ventas
Dimensión de cliente
Una cuenta comercial tal como era en cada fecha, vinculada a sus entidades legales y clientes del ERP.
- Granularidad
- Una fila por cuenta y periodo de validez
- Clave
Clave analítica de cliente- Frescura
- Cada hora, a partir de eventos del CRM
- Responsable
- Responsable del dato en el CRM
05Dimensión clave · Granularidad, identidad y frescura
Cuatro fuentes, cuatro granularidades, un solo punto de encuentro
Cada fuente conserva su granularidad nativa. Solo se comparan a una granularidad conformada, con reglas para lo que llega tarde y lo que se corrige.
- Líneas de pedido
- Granularidad nativa
- Línea de pedido × versión
- Llega
- A diario, el mismo día
- Correcciones
- Nueva versión; cancelado es un estado
- Líneas de factura
- Granularidad nativa
- Línea de factura contabilizada
- Llega
- A diario, a menudo un día después del pedido
- Correcciones
- Línea de abono, nunca una edición
- Objetivos
- Granularidad nativa
- Cuenta × línea de producto × mes
- Llega
- Al publicarse, a veces a mitad de año
- Correcciones
- Nueva versión del objetivo
- Cuentas
- Granularidad nativa
- Cuenta × periodo de validez
- Llega
- Eventos cada hora
- Correcciones
- La fusión conserva la clave superviviente; el histórico se reasigna
Cuenta × línea de producto × mes
- Pedidos y facturas se agregan por separado y se comparan a esta granularidad; nunca se cruzan línea a línea.
- Un objetivo de año parcial cuenta desde su mes de vigencia; los meses anteriores no tienen objetivo, no un cero.
- Un mes sigue siendo provisional hasta el cierre financiero; las facturas tardías lo recalculan.
- Los pedidos cancelados conservan su histórico y salen de los pedidos abiertos.
- Los importes se convierten una sola vez, al tipo de reporting, en la plataforma de datos.
La decisión de granularidad es la arquitectura. Todas las métricas posteriores la heredan.
07Fallo y recuperación
Diseñar el camino del fallo antes que el camino feliz.
- Las facturas llegan un día después que los pedidosCompletitud por sociedad y díaMarcar el mes como provisional; recalcular cuando lleguenEquipo de la plataforma de datos
- Un pedido se cancela después de haberse contadoNueva versión del pedido con estado canceladoGana la última versión; el histórico conserva ambasResponsable del dato en el ERP
- Un cliente del ERP no se corresponde con ninguna cuenta del CRMControl de clientes sin asignar en cada cargaAparcar como «sin asignar» y derivar a datos maestros; nunca descartar la facturaciónDatos maestros
- Un objetivo se republica a mitad de añoNueva versión del objetivoRecalcular los meses afectados; conservar la versión anterior para auditoríaOperaciones de ventas
08Arquitecturas candidatas
Opciones creíbles, evaluadas frente a estas premisas.
Copiar las transacciones en el CRM
Pocas transacciones, una sola sociedad
Coste: Volumen en el CRM, sin histórico fechado, cada equipo recalculaHacer informes directamente desde cada fuente
Una fuente por pregunta
Coste: Granularidades y tiempos distintos dan respuestas distintas a la misma preguntaConformar en la plataforma de datos y publicar métricas
Varias fuentes y sociedades, definiciones compartidas
Coste: Requiere contratos de granularidad e identidad y un compromiso de frescura09La segunda capa
Preguntas que cambian el diseño.
Granularidad
- ¿Cuál es la granularidad de cada conjunto de datos?
- ¿Se pueden cruzar las líneas de pedido y de factura, o solo compararlas a una granularidad compartida?
- ¿Cómo se representan los objetivos de año parcial?
Tiempos
- ¿Qué pasa cuando una fuente se actualiza más tarde que otra?
- ¿Cuándo es definitivo un periodo?
- ¿Cómo se representan las transacciones canceladas o corregidas?
Significado
- ¿Cómo se identifica a los clientes de forma coherente?
- ¿Qué divisa es la de referencia?
- ¿Dónde se calculan las métricas y cómo se activan en el CRM?
10Decisiones y entregables
Qué produce el trabajo.
- 01Modelo canónico de granularidad
- 02Identidad de cliente conformada
- 03Contratos de conjuntos de datos
- 04Contratos de métrica
- 05Reglas de frescura y cierre de periodo
- 06Modelo de activación