Modelar para Power BI (I): datamarts, KPIs y una única versión de la verdad

Cuando un informe de Power BI no cuadra, el problema casi nunca está en el gráfico. Está antes: en un indicador que cada área calcula a su manera, en una tabla con más detalle del necesario o en una fórmula que nadie decidió cómo debía comportarse cuando el denominador es cero. Esta serie recorre cómo modelar bien para Power BI, de principio a fin. En esta primera parte nos centramos en lo que hay que resolver antes de construir ninguna tabla: el papel del datamart y la definición de los indicadores. En la segunda parte pasamos al diseño dimensional y al modelo semántico.

Usaremos como hilo conductor el sector asegurador (pólizas, primas, siniestros y reservas), pero los principios sirven para cualquier negocio.

El datamart: el puente entre el data warehouse y el negocio

Un datamart es un subconjunto temático del data warehouse corporativo, orientado a un área de negocio concreta. En una aseguradora puede haber uno de siniestros, otro de producción comercial y otro de reservas técnicas. Mientras el data warehouse integra la información de toda la organización, cada datamart ofrece una vista depurada y optimizada de lo que un equipo necesita.

Sus ventajas son prácticas:

• Velocidad. Al contener solo los datos de un dominio, las consultas e informes responden mucho más rápido que sobre el almacén completo.
• Sencillez y autoservicio seguro. Una estructura en estrella con tablas como Siniestros, Cliente, Producto y Fecha es comprensible para un analista de negocio; un modelo corporativo con cientos de tablas, no.
• Adaptación al área. Puede incorporar cálculos propios, como provisiones acumuladas o segmentaciones de riesgo del área actuarial, sin dejar de partir de los datos oficiales.
• Gobierno local. Hereda la calidad del almacén corporativo y añade las reglas del área (por ejemplo, trabajar solo con los últimos cinco años) sin tocar el modelo global.

Un datamart bien concebido es el equilibrio entre el gobierno corporativo y la agilidad departamental.

Dependiente o independiente

Hay dos maneras de construirlos:

	Datamart dependiente	Datamart independiente
Origen	El data warehouse corporativo	Directamente las fuentes operacionales o externas
Ventaja	Datos ya integrados y depurados: una sola fuente de verdad	Agilidad: se puede empezar sin un almacén central
Riesgo	Creer que la consistencia de los KPIs está garantizada	Definiciones distintas entre departamentos

El enfoque dependiente es el más recomendado cuando existe un data warehouse. El independiente, asociado al enfoque incremental de Kimball, es válido para atender necesidades urgentes y crecer por partes. Pero en los dos casos hay una trampa: que los datos vengan de la misma fuente no garantiza que los indicadores se calculen igual. Eso solo lo asegura un mapa global de KPIs, un glosario compartido y un gobierno del dato que los mantenga.

Primero los KPIs, después las tablas

Antes de diseñar nada hay que aclarar qué quiere medir el negocio. Eso significa sentarse con quien usa los datos (responsables de siniestros, de ventas, de riesgos, actuarios y dirección) y recorrer tres pasos: identificar qué indicadores necesitan, documentar cómo se calcula cada uno y validar la interpretación antes de implementar.

Los indicadores de un sector parecen obvios hasta que se preguntan los detalles:

• Pólizas canceladas en el mes: ¿incluye las no renovaciones o solo las cancelaciones anticipadas?
• Primas emitidas en el trimestre: ¿brutas o netas de comisiones?
• Ratio de siniestralidad por producto: (indemnizaciones pagadas + reservas) / primas devengadas, pero ¿con qué reservas y a qué fecha?
• Tiempo medio de resolución de siniestros: ¿desde la apertura hasta el cierre o hasta el primer pago?
• Tasa de conversión de cotizaciones y valor de vida del cliente: ¿en qué ventana de tiempo?

Cada pregunta sin respuesta es una cifra distinta en dos informes.

El mapa de indicadores

Con las respuestas se construye el mapa de indicadores del área: una ficha por KPI que guía todo el diseño posterior del datamart y del modelo, y que otros datamarts pueden reutilizar cuando comparten indicadores.

Campo	Qué recoge
Definición de negocio	Qué mide el indicador y por qué importa, en lenguaje de negocio
Fórmula de cálculo	Numerador, denominador y filtros, sin ambigüedad
Datos necesarios	Tablas, campos y transformaciones del data warehouse
Reglas de negocio	Exclusiones, casos especiales, nulos y valores atípicos

Por ejemplo, la tasa de cancelación de pólizas quedaría así: porcentaje de pólizas canceladas en el periodo sobre el total de pólizas activas al inicio; excluye las no renovaciones naturales por vencimiento; incluye solo las cancelaciones solicitadas por el cliente o por impago.

Una única versión de la verdad

Imagina que la dirección financiera pide la tasa de retención de clientes y recibe tres informes con tres cifras: 87 %, 82 % y 91 %. Ventas cuenta compras repetidas, Finanzas mira ingresos retenidos y Marketing, fidelidad por campañas. Las tres son «la tasa de retención». El resultado es conocido: desconfianza en los datos, horas perdidas conciliando números y decisiones tomadas sobre la cifra equivocada.

La solución es que cada KPI tenga una única definición acordada y que esa lógica se implemente una sola vez, en el datamart como campo calculado o en el modelo semántico como medida DAX, para que todos los informes la reutilicen. Así se apoya en tres pilares:

1. Un repositorio central de métricas (el mapa global de KPIs), accesible para todos, con versiones y auditable.
2. Un proceso formal de definición, con un responsable que aprueba cada métrica y sus cambios.
3. Consistencia entre datamarts: mismo nombre de métrica, mismo cálculo en todos; validación centralizada y comprobaciones automáticas en las cargas.

Nombrar los KPIs con criterio

Una convención de nombres hace que el nombre técnico explique qué representa. Un esquema que funciona bien combina cuatro piezas: FÓRMULA_CONCEPTO_CATEGORÍA_PERIODO.

• Fórmula: Num (conteo), Suma, Promedio, DiferenciaPorc (variación porcentual), Delta (variación relativa).
• Concepto: qué se mide (Cancelaciones, Siniestros, Primas, Reservas, Saldo).
• Categoría: producto o segmento (AUTO, HOGAR, VIDA, SALUD, EMPRESAS).
• Periodo: Hace0 (mes actual), Ult3, Ult12, 0y5 (mes actual frente a hace cinco meses).

Nombre técnico	Significado
Num_Cancelaciones_AUTO_Hace0	Pólizas de Auto canceladas en el mes actual
Suma_Siniestros_HOGAR_Ult12	Importe de siniestros de Hogar en los últimos 12 meses
Promedio_Saldo_VIDA_Ult3	Saldo medio de reservas de Vida en los últimos 3 meses
Delta_Reservas_EMPRESAS_0y12	Variación de reservas de Empresas frente a hace un año

No es la única convención posible, y si la organización ya tiene una, conviene partir de ella. Este ejemplo asume periodos mensuales; si un mismo modelo mezcla escalas, se añade la unidad (Hace3M, Ult7D).

Los casos extremos: el ejemplo de la variación

Las fórmulas de variación parecen triviales:

Delta = (valor actual − valor anterior) / valor anterior

Si las reservas pasan de 300 a 100 millones, la variación es −67 %. Hasta aquí, todo claro. Pero en la práctica aparecen situaciones que la fórmula no sabe interpretar:

Antes	Ahora	Resultado de la fórmula	Regla que hay que acordar
−200 M	+100 M	−150 %	Pasar de déficit a superávit no es una caída: «recuperación» o «∞»
+200 M	−100 M	−150 %	Comunicarlo como pérdida total (−100 %)
0	+100 M	División por cero	«Nuevo» o crecimiento no definido
+100 M	0	−100 %	Pérdida total, interpretación clara

Ninguna de estas decisiones es técnica: las toma el negocio y se documentan en el mapa de KPIs. Después se implementan con lógica condicional en SQL (CASE WHEN) o en DAX:

Delta Reservas 0y2 =
VAR Actual = [Saldo Reservas]
VAR Anterior = CALCULATE ( [Saldo Reservas], DATEADD ( 'Fecha'[Fecha], -2, MONTH ) )
RETURN
    SWITCH (
        TRUE (),
        ISBLANK ( Anterior ) || Anterior = 0, BLANK (),   -- de nada a algo: se muestra como «nuevo»
        Anterior < 0 && Actual >= 0, BLANK (),            -- cambio de signo: regla acordada
        Anterior > 0 && Actual < 0, -1,                   -- pérdida total
        DIVIDE ( Actual - Anterior, Anterior )
    )

Y si varios datamarts calculan variaciones (siniestros, primas, reservas), todos deben tratar estos casos igual.

Otros indicadores con trampa

La variación es solo un ejemplo. Casi todas las métricas habituales tienen casos que hay que decidir:

• Tasa de conversión: ¿qué pasa sin visitas o cotizaciones? ¿Cuenta dos veces el mismo cliente? ¿En qué ventana de tiempo?
• Crecimiento interanual: productos nuevos sin año anterior, productos retirados, negocios estacionales con meses a cero.
• Tiempo medio de resolución: casos abiertos, valores atípicos, horas hábiles o naturales, expedientes reabiertos.
• Margen: ingresos negativos por devoluciones, periodos sin ingresos, qué costes se imputan.

Una plantilla para documentar cada métrica

Para que el mapa sea útil, todas las fichas siguen la misma plantilla:

• Identificación: nombre técnico, nombre de negocio, categoría, responsable, fecha de aprobación y versión.
• Definición de negocio: qué mide, por qué importa, quién la usa y con qué métricas se relaciona.
• Especificación técnica: fórmula exacta, fuentes, filtros, nivel de agregación, frecuencia de actualización e histórico disponible.
• Casos especiales: nulos, denominadores cero, negativos, atípicos, cambios de signo y datos sospechosos.
• Reglas de validación: rango esperado, comprobaciones cruzadas (retención + abandono ≈ 100 %), tendencias y conciliación con otra fuente.
• Notas de implementación: dónde se calcula (SQL o DAX), consideraciones de rendimiento, limitaciones conocidas e historial de cambios.

Cómo empezar

1. Elegir las métricas más críticas, unas veinte.
2. Reunir a todas las áreas que las usan y acordar sus definiciones.
3. Documentarlas con la plantilla antes de implementar nada.
4. Incorporar validaciones automáticas en las cargas.
5. Formar a los equipos en el uso del repositorio de métricas.
6. Crear un comité de gobierno del dato que apruebe altas y cambios.

Con los indicadores definidos, ya sabemos qué datos hacen falta y cómo deben comportarse. En la segunda parte vemos cómo derivar el datamart desde el data warehouse, diseñar el esquema en estrella y llevarlo a un modelo semántico en Power BI. Si quieres ir más allá del modelado, también tenemos una guía de buenas prácticas de modelado de datos en Power BI. Y si necesitas ayuda para ordenar tus indicadores, en Bidatia diseñamos cuadros de mando con Power BI y Microsoft Fabric partiendo precisamente de aquí.