Diseñar modelo de datos para reporting

«Lo hicimos hace seis meses pero ya no sirve. Necesitamos rehacerlo.» Es una frase que escuchamos con demasiada frecuencia cuando hablamos con empresas que han invertido en dashboards o reporting automatizado. El problema casi nunca es la herramienta de visualización. Es lo que hay debajo: el modelo de datos.

Un modelo de datos bien diseñado permite añadir nuevos informes, nuevas métricas y nuevas fuentes de datos sin tener que empezar de cero. Uno mal diseñado convierte cada nueva necesidad en un proyecto de reconstrucción. La diferencia entre ambos no es complejidad técnica: es metodología.

¿Por qué los modelos de datos se quedan obsoletos tan rápido?

Los motivos más frecuentes por los que un modelo de datos deja de funcionar son predecibles y evitables:

• Se diseñó para un informe concreto, no para una necesidad general. Si el modelo se construye para responder una sola pregunta («¿cuánto vendimos por producto el mes pasado?»), cuando la dirección pide otro análisis («¿cuál es el margen por cliente y canal?»), las tablas no lo soportan.
• No separa datos crudos de datos transformados. Las transformaciones y cálculos se hacen directamente sobre las tablas de origen. Cuando el origen cambia (un campo nuevo en el ERP, un formato diferente), todo se rompe.
• Las definiciones de KPIs están en los informes, no en el modelo. El margen bruto se calcula de una forma en el dashboard de ventas y de otra en el de finanzas. Nadie sabe cuál es la correcta.
• No contempla la evolución del negocio. Se abre una nueva línea de negocio, se añade un canal de venta, se cambia de ERP. Si el modelo no está preparado para estos cambios, hay que rehacerlo.

Los principios de un modelo de datos que dura

No hace falta ser un ingeniero de datos para entender los principios que hacen que un modelo de datos sea robusto. Estos son los más importantes:

Separar hechos de dimensiones

Es el principio más básico del modelado dimensional, y el que más se ignora en pymes. Los hechos son las transacciones o eventos (ventas, pedidos, entregas, tickets). Las dimensiones son el contexto (producto, cliente, fecha, zona, vendedor). Si mezclas ambos en una sola tabla gigante, cada consulta nueva es un calvario.

Definir los KPIs una sola vez

El margen bruto, la tasa de conversión, el OTIF, el coste por unidad: cada métrica debe tener una definición única en el modelo, consensuada con el negocio. Si el CFO y el COO usan definiciones distintas, el problema no es técnico: es organizativo. Y hay que resolverlo antes de construir el modelo, no después.

Construir en capas

Un modelo de datos robusto tiene al menos tres capas:

1. 1Capa de ingesta: los datos llegan tal cual desde los sistemas de origen. No se transforman, solo se almacenan. Si el origen cambia, solo hay que ajustar esta capa.
2. 2Capa de transformación: aquí se limpian, normalizan y enriquecen los datos. Se aplican las reglas de negocio, se resuelven las inconsistencias y se crean las tablas que alimentan los informes.
3. 3Capa de consumo: las tablas finales que usan los dashboards. Son las más simples, las más rápidas de consultar y las que el usuario final ve.

Esta separación en capas permite que un cambio en el ERP solo afecte a la capa de ingesta, que una nueva regla de cálculo solo modifique la capa de transformación, y que un nuevo informe solo requiera cambios en la capa de consumo. Sin esta estructura, un cambio en cualquier parte afecta a todo. Cuando esas capas dejan de caber dentro de la herramienta de reporting, el paso siguiente es montar esas capas en una plataforma de datos con su almacén y sus procesos de carga, y dejar el BI solo para el consumo.

Errores frecuentes que complican la evolución

• Hardcodear valores en el modelo. Si el cálculo del IVA asume siempre un 21%, el día que cambie la legislación o trabajes con países con tipos distintos, habrá que revisar todo el modelo.
• No documentar las transformaciones. Si la persona que diseñó el modelo se va y nadie sabe por qué se aplica un filtro o un cálculo específico, cualquier modificación es un riesgo.
• Optimizar prematuramente. En pymes con volúmenes de datos razonables, la velocidad de consulta rara vez es un problema. Diseñar para legibilidad y mantenibilidad es más importante que diseñar para rendimiento.
• Ignorar la gestión de cambios. El modelo debe tener un proceso para incorporar nuevos requisitos: quién solicita, quién valida, quién implementa. Sin esto, el modelo se degrada con cada «añádeme este campo rápido».

Ejemplo práctico: modelo para reporting comercial

Supongamos una empresa mediana con un ERP (ventas, pedidos, clientes) y un CRM (leads, oportunidades, actividades comerciales). La dirección quiere un dashboard que responda a estas preguntas: ventas por producto, cliente y zona; evolución mensual comparada con el año anterior; pipeline comercial por etapa; y tasa de conversión de lead a cliente.

Un enfoque ingenuo sería crear una tabla plana con todas las columnas necesarias mezcladas. El enfoque correcto separa los datos en tablas de hechos y dimensiones:

• Tabla de hechos de ventas: fecha, producto, cliente, zona, importe, coste, cantidad. Una fila por línea de pedido.
• Tabla de hechos de pipeline: fecha, oportunidad, etapa, importe esperado, probabilidad, comercial asignado.
• Dimensión de productos: código, nombre, categoría, familia, estado (activo/descatalogado).
• Dimensión de clientes: código, nombre, sector, tamaño, zona geográfica, fecha de alta.
• Dimensión de tiempo: fecha, mes, trimestre, año, semana del año. Construida como tabla independiente que permite comparativas temporales sin ambigüedad.
• Dimensión de comerciales: nombre, equipo, zona asignada, fecha de incorporación.

Con esta estructura, añadir un nuevo informe (por ejemplo, rendimiento por comercial o análisis de descuentos) no requiere tocar las tablas existentes: basta con añadir una nueva medida o una nueva dimensión. Es la diferencia entre un modelo que crece y uno que se rompe.

Herramientas y tecnologías: qué encaja en cada escenario

La elección de herramienta depende del volumen de datos, del equipo disponible y del ecosistema tecnológico de la empresa. No hay una solución universal, pero sí hay combinaciones que funcionan bien para la empresa mediana española:

Lo importante no es la herramienta sino la disciplina. Un modelo bien estructurado en Power Query dentro de Power BI es mejor que un modelo caótico en la herramienta más sofisticada del mercado. La clave es respetar las capas (ingesta, transformación, consumo) independientemente de la tecnología.

La prueba definitiva: ¿tu modelo sobrevive a un cambio de ERP?

Cambiar de ERP es uno de los momentos que más evidencia si el modelo de datos está bien diseñado. Si el modelo depende directamente de las tablas del ERP (nombres de campos, estructura específica, lógica del sistema de origen), el cambio de ERP obliga a reconstruir todo el reporting desde cero.

Si el modelo tiene una capa de ingesta que abstrae el origen y una capa de transformación que aplica las reglas de negocio de forma independiente, el cambio de ERP solo afecta a la capa de ingesta. Las transformaciones y los dashboards siguen funcionando porque trabajan sobre conceptos de negocio (ventas, clientes, productos), no sobre las tablas específicas de un sistema.

Gobierno del modelo: quién puede cambiar qué

Un modelo de datos que funciona el primer día pero se degrada en seis meses suele tener un problema de gobierno, no de diseño. Alguien añade un campo «rápido» en la capa de consumo saltándose la transformación. Otro cambia la definición de un KPI sin avisar al resto de áreas. Un tercero conecta una fuente nueva directamente al dashboard sin pasar por la capa de ingesta.

• Define quién puede modificar cada capa. La capa de ingesta la toca el equipo de datos. La capa de transformación requiere validación de negocio. La capa de consumo puede ser más flexible, pero dentro de los límites del modelo.
• Establece un proceso mínimo para nuevos requisitos. No hace falta burocracia, pero sí un canal claro: «necesito una nueva métrica» pasa por una validación de definición antes de implementarse.
• Documenta las decisiones de diseño. No todo el modelo, pero sí las decisiones no obvias: por qué se excluyen ciertas transacciones, cómo se calcula el margen, qué filtros se aplican por defecto. Un documento breve con estas decisiones vale más que un diagrama completo del modelo.
• Revisa el modelo trimestralmente. Una revisión rápida cada trimestre para detectar campos no usados, medidas duplicadas o transformaciones que ya no aplican mantiene el modelo limpio sin gran esfuerzo.

Cómo empezar bien desde el primer día

Si estás a punto de montar tu primer modelo de datos para reporting o sospechas que el actual necesita una revisión, el proceso empieza siempre por lo mismo: definir qué preguntas de negocio necesitas responder, identificar las fuentes de datos y acordar las definiciones de los KPIs con los responsables de cada área. La tecnología viene después. Si necesitas ayuda para diseñar esa base, nuestro equipo de análisis de datos trabaja exactamente con este enfoque, y si ya tienes datos en Power BI o similar, la consultoría de Power BI incluye la auditoría del modelo existente como punto de partida.

Si te interesa profundizar, en automatizar reporting financiero en 3 pasos exploramos este tema en detalle.

Para más contexto, puedes consultar la informe de Gartner sobre datos listos para IA.