Si una métrica no guía una decisión, elimínela

Casi todas las empresas tienen algún dashboard. Muchas tienen demasiados. Pocas tienen una Single Source of Truth: un vocabulario de medición que liderazgo, marketing, ventas e IT usan sin discutir.

El síntoma habitual: tres hojas de cálculo, dos informes Power BI y un export del CRM contando historias distintas del mismo mes. El problema rara vez es «nos falta Power BI» o «necesitamos BigQuery». Está aguas arriba: fuentes sucias, integraciones que faltan, métricas sin owners.

El objetivo real del BI no es construir dashboards. Es acortar el tiempo entre una pregunta de negocio y una decisión fiable.

En Syncronika este recorrido vive en el perímetro de data analytics y en la página de reporting ejecutivo. Warehouses, lakes, BI e IA entran cuando sirven al recorrido, no como un proyecto de moda.

El recorrido en siete etapas

Esto no es un glosario. Es un viaje: cada etapa desbloquea la siguiente.

Recorrido: problema, fuentes, limpieza, integración, warehouse, BI, IA

Problema · números conflictivos, decisiones lentas
Fuentes de datos · CRM, e-commerce, ads, ERP (OLTP)
Limpieza · calidad, dedupe, reglas
Integración · batch o streaming, ETL / ELT
Warehouse · modelo, historial, Single Source of Truth
BI · capa de lectura + capa semántica («revenue» igual para todos)
IA dirigida · solo después de definiciones y pipelines

Puedes saltarte secciones. No saltes el orden: poner Power BI o IA en el paso 1 reproduce el desorden, más bonito.

1. El problema: no hay una sola verdad

Un dashboard solo se gana el puesto si responde a preguntas que alguien formula de verdad, con una cadencia, y con seguimiento.

Ejemplos honestos:

¿Qué leads merecen una llamada esta semana? (SaaS / servicios B2B)
¿Dónde se rompe el funnel entre campaña y pedido? (e-commerce)
¿Sube el coste de soporte por volumen o por calidad de datos? (servicios / helpdesk)
¿Aguanta el margen del canal X tras devoluciones? (retail / manufacturing)

Si nadie actúa sobre el número, quita el tile. Menos gráficos, más indicadores con owners.

Single Source of Truth significa: una definición compartida para cada métrica crítica, alimentada por fuentes gobernadas, legible por cada rol sin «mi versión de la hoja».

Sin ella, cada reunión reinicia con «mis números dicen otra cosa».

2. Fuentes de datos: donde todo empieza (o muere)

CRM, e-commerce, ads, helpdesk, ERP: típicamente bases OLTP (Online Transaction Processing). Aquí viven contactos, pedidos y tickets. Si los campos están duplicados, vacíos o contradictorios, ningún BI aguas abajo te salvará.

Haz primero data enrichment y CRM intelligence, luego los informes.

Ejemplos por sector

Contexto	Fuentes típicas	Pregunta que debe conciliar
E-commerce	Shopify / Magento, ads, almacén	Pedidos netos vs devoluciones por canal
B2B SaaS	CRM, billing, product analytics	Pipeline y churn en un solo vocabulario
Manufacturing	ERP, MES, calidad	Coste, scrap, lead time en un modelo
Servicios	CRM, helpdesk, timesheets	Margen por proyecto y SLAs

3. Limpieza: reglas antes que gráficos

Dedupe de clientes, campos obligatorios, controles de entrada, mapeo de IDs (CRM vs e-commerce vs billing). Trabajo poco glamuroso, y mucho más útil que un tercer Power BI.

Sin limpieza, cada pipeline copia el desorden al warehouse.

4. Integración: cómo llegan los datos al modelo

Del CRM a una decisión: ETL, warehouse, Power BI, manager

Batch o streaming

Batch (ventanas periódicas: noche, hora, cierre de día): ideal para maestros, pedidos consolidados, exports de ads, snapshots de ERP. Más fácil de auditar y reprocesar. Límite: los datos del BI quedan congelados en la ventana anterior.

Streaming (o casi tiempo real: webhooks, colas, CDC, clickstream): encaja con inventario, anomalías, soporte en vivo, campañas que deben reaccionar en minutos. Cuesta más en complejidad. Si nadie actúa en el minuto, es teatro.

Híbrido (la norma): batch para finanzas y warehouses «oficiales»; streaming solo donde la latencia cambia una decisión operativa.

La frecuencia de ingesta debe seguir la frecuencia de decisión, no al revés.

ETL y ELT: cómo entran los datos al warehouse

ETL (Extract, Transform, Load): extraer, transformar (limpieza, joins, reglas) y luego cargar en el warehouse. Útil cuando quieres controlar la transformación antes de tocar el almacén analítico.

ELT (Extract, Load, Transform): cargar primero (incluso en bruto) en el warehouse o lake, y transformar allí (SQL, dbt, procedimientos). Útil con motores cloud elásticos (BigQuery, Snowflake, Fabric) donde la transformación escala mejor en destino.

Esto no es una guerra de acrónimos. Es una elección de dónde vive la lógica de negocio y quién la versiona.

Cuando diseñas integraciones, pregunta: ¿batch, streaming o ambos? ¿ETL o ELT? ¿Qué SLA de frescura? ¿Quién reprocesa cuando falla una carga?

5. Warehouse (y lake): hogar de la verdad analítica

OLTP y OLAP: dos bases, dos trabajos

OLTP vs OLAP

OLTP: escribe el presente. Ejemplos: PostgreSQL, MySQL / MariaDB, SQL Server, Oracle (a menudo detrás del CRM o e-commerce, o en RDS / Cloud SQL).

OLAP: explica el pasado y prepara la decisión. Ejemplos: BigQuery, Snowflake, Amazon Redshift, Microsoft Fabric / Azure Synapse, Databricks SQL; en setups más ligeros también ClickHouse. Power BI suele leer desde aquí, no desde el Postgres de producción.

Error clásico: informes pesados sobre MySQL/Postgres de producción. Error opuesto: un warehouse que copia fuentes sucias.

Cuándo un warehouse se vuelve útil

Un warehouse se vuelve útil cuando las decisiones empiezan a depender de datos de múltiples sistemas, cuando necesitas historial fiable, cuando quieres versionar KPIs, o cuando la base operativa ya no es el lugar correcto para el análisis (locks, timeouts, números que se mueven mientras alguien guarda).

No es «solo si eres grande». Es «cuando el análisis ya no puede vivir dentro del ERP».

Un data lake guarda datos en bruto o semiestructurados (logs, eventos, archivos). Ayuda con alto volumen o experimentos. No ayuda si el problema es «ventas no confía en el CRM».

En resumen: lake = archivo en bruto, warehouse = modelo para decisiones, BI = capa de lectura.

Desnormalizar para BI

En bases OLTP los datos suelen estar normalizados. En el lado OLAP suele desnormalizarse de forma controlada: modelo en estrella (hechos + dimensiones anchas), claves canónicas, menos joins inventados en Power BI.

No un CSV monstruo. Un modelo de lectura donde marketing y finanzas obtienen el mismo número.

dbt (mención esencial)

dbt (data build tool) es hoy un estándar de facto para modelar transformaciones en el warehouse: SQL versionado, tests, docs, entornos. No sustituye BigQuery ni Snowflake: los hace gobernables. Si alguien solo habla de «cargar tablas» sin cómo se versionan las transformaciones, pregunta por dbt (o un equivalente).

6. BI y la capa semántica: «revenue» igual para todos

Power BI es fuerte visualizando y distribuyendo informes en empresas muy Microsoft. Looker, Metabase y otros funcionan igual de bien. La herramienta importa menos que tres condiciones:

Definiciones compartidas
Pipelines fiables
Ritual de revisión (métricas que se pueden eliminar)

La capa semántica

Hoy el problema real a menudo no es el dashboard. Es tener «revenue» igual para todos.

La capa semántica es donde viven las métricas de negocio y las relaciones, independientes de cualquier informe concreto:

Power BI Semantic Model / Microsoft Fabric Semantic Model
LookML (Looker)
dbt Metrics / MetricFlow
Cube, AtScale, Transform y otras capas de métricas

Sin ella, cada analista reinventa el KPI en DAX o SQL. Con ella, la Single Source of Truth se vuelve consultable.

Si dos equipos deben discutir la fórmula de «ingresos netos» dentro del gráfico, la capa semántica aún no está.

7. Dónde ayuda la IA (y dónde no)

La IA sobre datos es útil en sitios precisos. No como sustituto de un modelo de medición.

Tiene sentido cuando:

clasificas tickets, notas o documentos (ver procesamiento documental);
señales anomalías («tasa de devolución fuera de umbral en el canal Y»);
resumes métricas ya gobernadas para el liderazgo;
aceleras mapeo y limpieza bajo supervisión humana.

No tiene sentido cuando:

pides a un modelo que invente el KPI que falta;
usas un agente para narrar números conflictivos como una sola verdad;
compras un copiloto de BI antes de owners, definiciones y capa semántica.

Como en ¿IA en todas partes? A menudo aún se resuelve sin IA, muchas empresas arreglan primero reglas, integraciones y calidad de datos.

Gobernanza de datos: quién decide sobre la métrica

No basta saber quién actualiza los datos. También hace falta:

quién puede cambiarlos;
quién aprueba una métrica;
quién cambia una definición (p. ej. «lead cualificado»);
dónde vive la documentación (capa semántica, dbt, wiki).

Eso es gobernanza de datos. Sin ella, la Single Source of Truth se degrada en el primer turnover o en el primer «hotfix» de Power BI.

El ritual breve de revisión (cadencia, acciones, métricas a eliminar) es gobernanza en la práctica, no solo política.

Checklist operativa (sin programa a tres años)

Inventario de fuentes y owners
Reglas de limpieza y calidad
Métricas mínimas compartidas (incluso CRM + una hoja controlada)
Integraciones estables (batch/streaming, ETL/ELT)
Modelo desnormalizado + transformaciones versionadas (dbt o equivalente)
Warehouse cuando multi-fuente, historial o separación de ops lo exigen
BI cableado a la capa semántica, no a APIs aleatorias
IA dirigida, con métricas de control

Cada paso tiene un stop. Esto es reporting ejecutivo cableado a stacks reales, no una data platform de brochure.

Qué preguntar al siguiente proveedor (o a tu equipo interno)

¿Qué decisiones cambiarán?
¿Quién posee cada métrica y quién aprueba su definición?
¿Qué sistemas, con qué frescura (batch/streaming), ETL o ELT?
¿Cómo construís la Single Source of Truth y la capa semántica?
¿Usáis dbt (o equivalente) para versionar transformaciones?
¿Dónde proponéis IA, y cómo medís menos errores frente a más slides?

Si las respuestas son vagas, estás comprando herramientas, no decisiones.

Por dónde empezar

Si hoy coexisten hojas paralelas, un Power BI apenas usado y un CRM en el que no se confía, no empieces por el logo del cloud. Empieza por decisiones y fuentes. Luego integración, warehouse, capa semántica. La IA llega después.