Ícaro Iasbeck
La estrategia detrás de la operación

Data warehouse y BI: 6 señales de que el CRM no basta

El reporte del CRM responde bien al pipeline y falla cuando la dirección pregunta por cohortes, NRR o margen por cliente, porque esas cuentas cruzan sistemas y piden historial. Las señales de que llegó la hora del data warehouse, qué es cada pieza, la arquitectura mínima por etapa y quién responde por ella.

18 min de lectura

La operación de ingresos necesita data warehouse y BI cuando las preguntas de la dirección empiezan a cruzar el CRM con sistemas que él no guarda, como el ERP, el producto y finanzas, o cuando piden un historial que el CRM no conserva, como la foto de la base al cierre de cada mes para calcular el NRR y la retención por cohorte. Mientras la pregunta cabe en el pipeline, el reporte del propio CRM la resuelve con menos costo. El data warehouse es la base de datos analítica que recibe una copia de los sistemas de la operación y guarda su historial, y el BI es la herramienta que convierte esa base en paneles y análisis. Los dos devuelven la inversión solo cuando cada métrica tiene una definición escrita, un dueño y una reunión que la usa. En una encuesta a 566 líderes de datos y analítica, solo el 44% dijo que su equipo es eficaz en generar valor para la organización, y los seis mayores obstáculos que señaló la encuesta estaban ligados a personas (Gartner, 2023).

La conversación sobre el warehouse suele empezar en una reunión de directorio. El director financiero pregunta cuál fue la retención neta de los clientes que entraron en 2024, por segmento, y cuánto margen dejó cada grupo después del descuento. El CRM sabe quién cerró, el ERP sabe cuánto pagó cada cliente, y ninguno de los dos responde solo. Alguien de operaciones pasa tres días cruzando planillas por el nombre de la empresa, y el número llega a la reunión siguiente distinto del que trajo finanzas. Los paneles que el CRM arma bien están en dashboard comercial y siguen ahí después del warehouse, que entra para las preguntas que atraviesan sistemas.

¿Cuándo deja de bastar el reporte del CRM?

El CRM guarda el estado actual de la relación comercial y responde bien a lo que vive en él, como etapas, negocios y dueños de cuenta. Tropieza con dos tipos de pregunta. El primero depende de datos de otro sistema, como facturación, margen o uso del producto. El segundo depende de cómo estaba la base en el pasado, porque el CRM sobrescribe el valor del contrato cuando cambia, y sin la foto del mes anterior nadie sabe cuánto del ingreso de marzo vino de expansión. La retención por cohorte, que sigue mes a mes al grupo de clientes que empezó en el mismo período, y el LTV por segmento juntan los dos problemas, y sus fórmulas están en métricas de RevOps.

Aplico el diagnóstico de abajo con la dirección antes de cualquier conversación sobre herramientas. Cada señal vale 0, 1 o 2 puntos, con 1 para el punto medio.

Señal Pregunta de verificación Vale 2 cuando Vale 0 cuando
Datos financieros fuera del CRM ¿La dirección pide facturación, margen o morosidad por segmento o vendedor? Toda reunión mensual depende de cruzar planillas del ERP La integración trae esos campos al CRM
Uso del producto ¿Ventas y CS necesitan ver el uso del producto por cuenta? El dato de uso existe y no llega a quien atiende la cuenta La empresa no tiene producto digital o el uso no pesa en la renovación
Historial fechado ¿Alguien necesita saber cómo estaban la base o el pipeline en una fecha pasada? NRR, GRR y pipeline del inicio del trimestre salen de planillas guardadas a mano Las preguntas tratan solo del estado actual
Cohorte, LTV y NRR ¿El liderazgo sigue la retención por cohorte de entrada y el LTV por segmento? El directorio o los inversionistas piden esos números cada trimestre Ninguna decisión usa esas métricas
Horas de cruce ¿Cuánto tiempo gasta el equipo por mes cruzando planillas? Más de dos días de una persona Menos de medio día
Versiones del mismo número ¿Las áreas traen valores distintos para la misma métrica? Toda reunión empieza discutiendo qué número vale Hay una versión y nadie la cuestiona

Con hasta 4 puntos, el reporte del CRM y las integraciones resuelven. Entre 5 y 8 puntos, la empresa necesita un warehouse mínimo para las preguntas que marcaron 2. Desde 9, el proyecto pide patrocinador, presupuesto anual y hoja de ruta por etapas. La última señal merece cuidado, porque versiones distintas del mismo número revelan falta de definición, y un warehouse montado antes del glosario firmado copia la discusión a un sistema más caro.

¿Qué es cada pieza de un data warehouse, en lenguaje de directivo?

El dato sale de los sistemas de origen, llega al warehouse, se convierte en tabla de negocio, recibe una regla de cálculo, aparece en el panel y, en algunos casos, vuelve al CRM. El diseño completo, con el sistema maestro de cada dato, está en arquitectura de datos de ingresos.

Extracción y carga (ELT)

ELT significa extraer, cargar y transformar. Los conectores copian las tablas de los sistemas al warehouse en intervalos acordados, y la transformación ocurre después, dentro del warehouse. El orden le interesa al directivo porque la copia en bruto queda guardada, y cuando la empresa cambia una regla de cálculo, el analista recalcula el pasado sin pedir una nueva exportación. El liderazgo decide la frecuencia: el panel de la reunión mensual convive bien con una carga diaria, y la carga cada pocos minutos solo compensa cuando alguien actúa el mismo día.

Data warehouse

El warehouse es una base de datos hecha para análisis, separada de los sistemas que mueven la operación. La separación protege al CRM de consultas pesadas y permite guardar fotos fechadas de las tablas, lo que los técnicos llaman snapshot: la cartera de contratos tal como estaba el último día de cada mes, por ejemplo. Con esas fotos, la cuenta del NRR deja de depender de la planilla que alguien se acordó de guardar.

Modelado

Modelar es transformar las tablas en bruto de cada sistema en tablas que el liderazgo reconoce: cliente, contrato, ingreso recurrente por mes, oportunidad y ticket. La pieza que sostiene todo es la clave que une al mismo cliente en todos los sistemas, en general el número de identificación fiscal de la empresa. La literatura de modelado dimensional llama dimensiones conformadas a las tablas de referencia, como cliente y producto, que tienen los mismos nombres y valores en todos los análisis, y describe esa estandarización como “la esencia de la integración”, con las definiciones hechas una sola vez junto a los representantes de gobierno de datos del negocio (Kimball y Ross, 2013).

Capa semántica

La capa semántica guarda la regla de cálculo de cada métrica una sola vez, con nombre, fórmula, filtros y período, y todo panel, planilla conectada o agente de IA lee de ahí. Sin ella, cada panel recalcula el NRR a su manera, y dos pantallas del mismo BI llegan a números distintos. La definición en lenguaje de negocio, con dueño y ejemplos, vive en el diccionario de datos, y la capa semántica es la versión ejecutable de ese documento.

BI

El BI es la capa visible: paneles, filtros, análisis por segmento y el control de quién ve qué. Suele ser la primera compra y debería ser la última elección, porque depende de todo lo que viene antes.

Reverse ETL

El reverse ETL es la carga en sentido contrario: el warehouse devuelve al CRM y a la herramienta de atención el dato que calculó, como facturas vencidas, uso del producto y puntaje de salud de la cuenta. El vendedor y CS ven la información en el registro del cliente sin abrir el BI. La regla que aplico es escribir solo en campos cuyo maestro es el warehouse, marcados como de solo lectura en el CRM, siguiendo el mapa de datos descrito en stack de RevOps.

¿Cuál es la arquitectura mínima para cada etapa?

La arquitectura crece con la pregunta que la dirección necesita responder. La empresa de la primera etapa que compra la arquitectura de la tercera paga por preguntas que nadie hace, y la de la segunda que insiste en planillas pierde la foto de cada mes que pasa. La tabla muestra lo mínimo que resuelve cada etapa.

Etapa Situación típica Arquitectura mínima Quién la opera
CRM y ERP integrados, un área comercial Las preguntas caben en el pipeline; finanzas cruza la facturación una vez al mes Reportes en el CRM, campos de facturación que vienen del ERP y una exportación mensual fechada de la cartera, en una carpeta controlada Administrador del CRM, con finanzas
De tres a cinco sistemas, dirección pidiendo NRR y CAC por segmento El cierre mensual consume días de cruce manual Conectores gestionados, warehouse con cobro por uso, modelado de cliente, contrato e ingreso mensual, fotos mensuales y BI con la pantalla de la dirección Un analista de RevOps o de datos, con apoyo externo en el armado
Varias unidades de negocio o producto digital con datos de uso Directorio e inversionistas piden cohorte, LTV y retención por línea de ingreso La etapa anterior más capa semántica, pruebas de calidad en las cargas, reverse ETL y catálogo de datos Equipo de datos con ingeniería analítica y un dueño de negocio por dominio

¿Quién es dueño del data warehouse y de cada número?

El negocio responde por la definición y la tecnología responde por las tuberías. El error más caro que veo es entregarle el warehouse a TI y esperar que decida qué cuenta como cliente activo o como churn. TI no tiene mandato para arbitrar entre ventas, CS y finanzas, y las áreas rechazan el número que ella define. La matriz de abajo separa quién responde, quién ejecuta y quién aprueba.

Actividad Responde Ejecuta Aprueba
Definición de cada métrica Área dueña de la métrica: dirección comercial, CS o finanzas Operaciones de ingresos la escribe en el diccionario de datos Comité de ingresos de la dirección
Regla de cálculo en la capa semántica Operaciones de ingresos o datos Analista o ingeniero analítico Área dueña, después de comparar con una cuenta manual
Conectores, cargas y fotos mensuales Datos o TI Ingeniería analítica TI, por acceso y seguridad
Calidad del dato en el origen Liderazgo de cada área que registra Equipos de marketing, ventas y CS Responsable de la base del CRM
Acceso y datos personales en el warehouse TI, con el encargado de protección de datos Administrador del warehouse Encargado de protección de datos y área legal
Panel de la dirección Dirección que usa el panel Analista de RevOps Dirección
Reverse ETL al CRM Operaciones de ingresos Ingeniería analítica Administrador del CRM

El patrocinador del proyecto necesita autoridad para arbitrar definiciones entre áreas, y por eso prefiero un director financiero o de operaciones a un director de área. Como el warehouse junta contactos, atención y uso en un solo lugar, el encargado de protección de datos aprueba quién accede a qué y por cuánto tiempo se guarda el historial.

¿Cuánto cuesta un data warehouse para la operación de ingresos?

El costo tiene cuatro componentes. Los conectores cobran por fuente o por volumen de filas copiadas, el warehouse cobra por almacenamiento y procesamiento, el BI cobra por usuario o por capacidad, y las personas que modelan, validan y mantienen el conjunto representan la mayor parte de la cuenta. En un ejemplo hipotético, una operación mediana gasta R$ 1.500 al mes en conectores, R$ 1.000 en warehouse y R$ 1.500 en BI, y paga R$ 18.000 mensuales, con cargas sociales, por una persona de ingeniería analítica. El año cierra en R$ 264.000, y el 82% de ese valor son personas.

La dirección suele aprobar la suscripción de las herramientas y olvidar a la persona que las va a mantener. El costo escondido viene del procesamiento: un panel configurado para actualizarse cada minuto, o una consulta mal escrita que lee la base entera cada vez que alguien la abre, multiplica la factura del warehouse. Pide un tope mensual de consumo con alerta y revisa cada trimestre las licencias de BI de quien no abrió ningún panel.

Errores comunes en proyectos de data warehouse y BI

Panel bonito con definición equivocada

El panel nuevo tiene filtros por segmento y actualización diaria, y la dirección confía en él por su apariencia. En un ejemplo hipotético, el modelo cuenta el churn por la fecha de fin del contrato, CS lo cuenta por la fecha del pedido de cancelación, y el mismo trimestre aparece con 4% de churn en el BI y 7% en la planilla de posventa. Antes de publicar cualquier métrica, el área dueña compara el resultado del panel con una cuenta manual de veinte clientes elegidos por ella, y la métrica solo entra en la reunión después de esa revisión.

El mismo dato en dos lugares

El NRR calculado en el reporte del CRM con un filtro y en el BI con otro produce dos versiones oficiales. Lo mismo ocurre cuando el reverse ETL escribe en un campo que el vendedor también edita, y la carga de la noche borra la corrección de la tarde. Cada número necesita una dirección: lo que es solo del pipeline queda en el CRM, lo que cruza sistemas queda en el warehouse, y ninguno de los dos calcula la métrica del otro.

BI que nadie abre

El BI registra cada acceso, y el liderazgo que lee ese registro antes de pedir el próximo panel descubre qué pantallas nadie visitó en el mes. Un panel sin reunión que lo use termina así. Aplico una regla simple: el panel sin acceso en sesenta días sale de la herramienta, y quien lo pidió escribe, para recrearlo, la pregunta y la reunión en la que va a aparecer.

Empezar por la herramienta y cargarlo todo

El proyecto que copia cuatrocientas tablas antes de elegir la primera pregunta pasa seis meses en infraestructura y llega a la dirección sin ningún número nuevo. En los proyectos de BI que acompaño, el primer mes rinde más cuando se dedica a definir las métricas que cuando se dedica a elegir la plataforma. La primera entrega responde de punta a punta a pocas preguntas de la dirección, y las tablas siguientes entran cuando una nueva pregunta las pida.

Data warehouse, BI e inteligencia artificial

El warehouse bien modelado sostiene la IA en la operación de ingresos por dos caminos. El primero es la pregunta en lenguaje natural: el director le pide al asistente el NRR del segmento industrial en el último trimestre, y el agente solo devuelve el número correcto si consulta la capa semántica, porque sin ella el modelo escribe la consulta y elige el filtro por su cuenta. El segundo es la predicción de riesgo de churn o de expansión, que aprende del historial fechado del warehouse y vuelve al CRM por el reverse ETL, con el origen marcado.

La falta de esa base derriba proyectos. En una encuesta a 1.203 líderes de gestión de datos, hecha en julio de 2024, el 63% de las organizaciones dijo no tener o no saber si tenía las prácticas de gestión de datos adecuadas para IA, y Gartner prevé que, hasta 2026, las organizaciones abandonarán el 60% de los proyectos de IA que no cuenten con datos preparados para IA (Gartner, 2025). Los efectos de poner un modelo sobre un CRM sin estructura están en IA sobre CRM desestructurado.

Capacitación: quién necesita aprender qué

En la encuesta de Gartner de 2023, el 39% de los líderes de datos citó la falta de talento entre los mayores obstáculos, y el comunicado recomienda formación en alfabetización de datos también fuera del equipo de datos. En la operación de ingresos, la dirección y los liderazgos necesitan leer cohorte, NRR y GRR, distinguir el número del CRM del número del warehouse y formular cada pregunta con su reunión y su decisión. Operaciones de ingresos aprende a mantener el diccionario y a validar el cálculo contra la cuenta manual, y el analista aprende modelado y capa semántica. Los equipos que registran en el CRM necesitan saber qué campo alimenta qué número del directorio, porque el warehouse hereda cada error de origen.

Hoja de ruta de 30 días para el liderazgo

La hoja de ruta termina con una decisión de inversión tomada sobre una prueba real, y los cuatro primeros pasos no exigen compras.

  1. Días 1 a 5: lista las preguntas y aplica el diagnóstico. Reúne las cinco preguntas que hoy dependen de planillas y puntúa las seis señales.
  2. Días 6 a 8: nombra al patrocinador y a los dueños. Elige quién arbitra las definiciones y asigna cada métrica de las cinco preguntas a un área dueña.
  3. Días 9 a 14: escribe las definiciones. Registra en el diccionario de datos fórmula, filtros, período y dueño de cada métrica, con la firma de los liderazgos.
  4. Días 15 a 18: mapea sistemas y claves. Para cada pregunta, lista los sistemas que cruza, la clave que une al cliente entre ellos y la calidad actual de ese campo.
  5. Días 19 a 21: elige la etapa de arquitectura. Usa la tabla de etapas y arma el presupuesto del primer año con herramientas, personas y tope de consumo.
  6. Días 22 a 28: construye una pregunta de punta a punta. Lleva la pregunta de mayor peso al warehouse o a la exportación controlada y compara el resultado con la cuenta manual del área dueña.
  7. Días 29 y 30: decide en la reunión de dirección. Presenta la prueba, el costo proyectado y el orden de las próximas preguntas, y registra en el acta la decisión de seguir, ajustar o parar.

Si tu dirección pregunta por cohortes, NRR y margen por cliente y recibe la respuesta en una planilla armada la víspera, ese es el trabajo de la formación in company de Revenue Operations. Conduzco el programa con los liderazgos de marketing, ventas y CS, finanzas, TI y la persona de operaciones en la misma sala, sobre las preguntas y los sistemas de tu operación. El grupo sale con el SLA entre marketing, ventas y CS, que define lo que cada área entrega y registra, y con la matriz de métricas de RevOps, que le da a cada número fórmula, dueño y sistema de origen, el punto de partida del diccionario y de la capa semántica.

Preguntas frecuentes

¿Qué es un data warehouse?

Es una base de datos hecha para análisis, separada de los sistemas que mueven la operación, que recibe una copia del CRM, del ERP y de las demás herramientas y guarda el historial de cada una. Permite cruzar datos de sistemas distintos y calcular métricas que dependen del pasado, como el NRR y la retención por cohorte.

¿Cuál es la diferencia entre data warehouse y BI?

El data warehouse guarda y organiza los datos; el BI es la herramienta que los muestra en paneles y análisis. El BI puede leer directo del CRM, pero solo cruza sistemas y muestra un historial confiable cuando lee de un warehouse modelado.

¿Toda empresa B2B necesita un data warehouse?

No. Si las preguntas de la dirección caben en el pipeline y la facturación llega al CRM por la integración con el ERP, los reportes del CRM resuelven con menos costo. El warehouse empieza a valer cuando la empresa necesita cruzar tres o más sistemas, guardar fotos mensuales de la base y seguir cohorte, LTV y NRR con regularidad.

¿Cuánto tiempo lleva implementar un data warehouse?

Una primera pregunta respondida de punta a punta cabe en pocas semanas cuando las definiciones están escritas y los sistemas comparten una clave común. La demora suele venir de la discusión de las definiciones y de la calidad del dato en el origen, y por eso la hoja de ruta empieza por ellas.

¿Qué es el reverse ETL?

Es la carga en sentido contrario: el warehouse devuelve al CRM y a la herramienta de atención datos que calculó, como facturas vencidas, uso del producto y puntaje de salud de la cuenta. El vendedor y CS pasan a ver esa información en el registro del cliente, en campos de solo lectura cuyo maestro es el warehouse.

¿Cómo preparar al equipo para usar el data warehouse y el BI?

Empieza por la dirección y los liderazgos, que necesitan leer cohorte, NRR y GRR y formular cada pregunta con la reunión y la decisión que sostiene. Después prepara a operaciones de ingresos para mantener el diccionario de datos y validar los cálculos, y muéstrales a quienes registran en el CRM qué campo alimenta cada número del directorio.

  • Data warehouse
  • BI
  • RevOps
  • Arquitectura de datos
Del texto a la práctica

¿Quieres llevar esto a tu equipo?

En el entrenamiento in company de Revenue Operations, el liderazgo diseña el SLA entre marketing, ventas y CS y sale con la matriz de métricas de la operación.

Llevar Revenue Operations a mi equipo