ADR / 002

Ubicar los KPI comerciales según su horizonte de acción

Elegir entre CRM, plataforma de datos o data warehouse por latencia y capacidad de acción, no por una pretensión universal de fuente de referencia.

Patrón de referencia

Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.

01Contexto

Los equipos comerciales necesitan avisos operativos, señales diarias de gestión y reporting histórico gobernado a partir de los mismos eventos de origen.

02Factores de decisión

  1. F01

    Latencia de la decisión

  2. F02

    Gobierno de las definiciones

  3. F03

    Proximidad a los datos de origen

  4. F04

    Reproducibilidad histórica

03Opciones consideradas

Selectiva

CRM

Acciones inmediatas a nivel de registro

Coste: Cálculo entre sistemas limitado
Elegida

Plataforma de datos

Señales multifuente casi en tiempo real

Coste: Dependencia operativa
Elegida

Data warehouse

Histórico gobernado y análisis complejo

Coste: Mayor latencia

04Decisión

Usar un modelo por niveles: calcular en el CRM las señales locales a la interacción, en la plataforma de datos la priorización casi en tiempo real y en el data warehouse las medidas históricas certificadas. Publicar las definiciones mediante un único contrato semántico.

05Consecuencias

  • Un mismo nombre de métrica no puede representar en silencio ventanas temporales distintas.
  • El CRM recibe decisiones y explicaciones, no complejidad analítica en bruto.
  • La reconstrucción con rigor financiero permanece en el data warehouse.

06Cuándo revisarla

01

La organización dispone de un único almacén operativo con controles suficientes.

02

Cambian de forma sustancial las expectativas de latencia o la responsabilidad sobre las definiciones semánticas.

07Dónde se aplica esta decisión

Casos que adoptan esta decisión, y por qué importa en cada uno.

  1. Caso de procesos / 03Diseñar un proceso de recuperación del rendimiento comercialConvertir una señal de bajo rendimiento en un responsable, un plan, una cadencia de revisión y un resultado registrado.Arquitectura de ProcesosRevenue OperationsDatos e IntegracionesEscenario ficticio · 8 min
  2. Caso de sistemas / 04Un solo CRM para varias modalidades comercialesUn núcleo de oportunidad compartido con etapas y extensiones propias de cada modalidad, para que cada una funcione a su manera mientras los forecasts y los informes siguen siendo comparables.Arquitectura de Sistemas y CRMRevenue OperationsArquitectura de ProcesosEscenario ficticio · 8 min
  3. Caso de datos / 02Convertir transacciones del ERP y objetivos en inteligencia comercialConformar pedidos, facturas, objetivos y cuentas a una granularidad declarada en la plataforma de datos, para que una única definición de métrica sirva a todos los equipos y su resultado llegue al CRM como señal gobernada.Datos e IntegracionesRevenue OperationsArquitectura de Sistemas y CRMEscenario ficticio · 9 min
  4. Caso de datos / 03Devolver señales analíticas al CRM operativoUn contrato de writeback para KPI y segmentos derivados: a nivel de cuenta, de solo lectura en el CRM, con sello de frescura y versión, conciliado con lo publicado y convertido en exactamente una tarea por señal.Datos e IntegracionesRevenue OperationsAutomatizaciónEscenario ficticio · 8 min
  5. Caso de datos / 05Evolucionar la analítica comercial de una sola divisa a variasConservar el importe original como hecho y el importe de reporting como una vista derivada y versionada, con una política de tipos declarada para datos reales, objetivos y umbrales, y el histórico de la V1 migrado sin reexpresar cifras.Datos e IntegracionesRevenue OperationsArquitectura de Sistemas y CRMEscenario ficticio · 7 min
  6. Caso de RevOps / 04Un modelo de objetivos con semántica de periodo explícitaLos objetivos como datos gobernados—granularidad, reparto, versión, precedencia, responsable y fecha de congelación—para que el rendimiento acumulado del año signifique lo mismo en cada informe y en cada mes.Revenue OperationsDatos e IntegracionesModelo Operativo DigitalEscenario ficticio · 7 min
  7. Caso de RevOps / 05Un forecast gobernado y una cobertura de pipeline que obligan a actuarCategorías de forecast derivadas de la semántica de las etapas, ajustes registrados en el nivel del forecast, un único responsable del número final, instantáneas semanales—y un contrato de cobertura cuyo umbral pone en marcha la generación de pipeline.Revenue OperationsDatos e IntegracionesArquitectura de Sistemas y CRMEscenario ficticio · 8 min
  8. Caso de RevOps / 06Llevar la cadencia de gestión comercial desde el CRMCuatro foros—diario, semanal, mensual, trimestral—, cada uno con participantes, evidencias, decisiones y resultados definidos, celebrados desde vistas del sistema en lugar de hojas exportadas y medidos con señales de adopción que muestran si la rutina es real.Revenue OperationsCambio y AdopciónModelo Operativo DigitalEscenario ficticio · 7 min
  9. Caso de IA / 02Preparar el contexto de la cuenta antes de una visita comercialUn agente reúne datos de cuenta, pipeline, pedidos, rendimiento e historial de visitas en un informe que separa hechos de inferencias, cita cada afirmación y no escribe nada de vuelta.IA y Flujos AgénticosRevenue OperationsDatos e IntegracionesEscenario ficticio · 7 min
  10. Caso de IA / 04Revisión de cuentas asistida por IA, con evidenciaUn agente prepara cada cuenta para la revisión mensual de rendimiento—objetivo, real, pipeline, actividad, segmento, plan de recuperación y cambios desde la última vez—como un resumen citado con anomalías y preguntas. Decide el responsable comercial.IA y Flujos AgénticosRevenue OperationsDatos e IntegracionesEscenario ficticio · 7 min