Kosta Cálida

01 · El punto de partida

Una red de tiendas genera datos constantemente. El reto es convertirlos en contexto.

Una red de tiendas puede acumular miles de tickets y tener muchos datos disponibles, pero eso no significa que la información sea fácil de utilizar. Los datos de ventas ya existían: el problema estaba en cómo utilizarlos.

Había información suficiente para conocer los resultados, pero no una estructura que permitiera analizar fácilmente qué había detrás de cada variación.

En este proyecto partí de datos de TPV y construí un sistema de reporting en Power BI pensado para pasar de una visión general del negocio al detalle que explica cada resultado. Planteé el proyecto desde una pregunta sencilla: ¿qué tendría que poder responder una persona de dirección cuando detecta que algo ha cambiado?

Mi objetivo era que una desviación en un KPI no terminara en una cifra, sino que pudiera seguirse hasta encontrar qué tienda, producto o ticket estaba detrás. A partir de ahí construí el modelo, las medidas y las páginas del informe para que el análisis pudiera avanzar desde el resumen hasta el detalle.

02 · El objetivo

De una desviación en un KPI al ticket que la explica.

Un KPI puede decirme que las ventas han bajado, pero eso es solo el principio del análisis. Quería que el informe permitiera seguir esa desviación y entender dónde se produce: qué tienda está detrás, qué productos están influyendo y qué ha ocurrido a nivel de ticket.

Por eso planteé el reporting con diferentes niveles de detalle. La idea es sencilla: empezar con una señal y poder profundizar hasta encontrar el contexto que la explica.

03 · Modelo de datos

Una estructura pensada para poder analizar las ventas desde distintos ángulos.

Antes de construir los gráficos, necesitaba ordenar bien los datos. La idea era que una misma venta pudiera relacionarse con su tienda, producto, fecha y presupuesto sin duplicar información ni complicar el análisis.

Para ello construí un esquema en estrella, una forma de organizar los datos que separa la información de las ventas y los presupuestos de los datos que utilizamos para analizarlos, como las tiendas, los productos o las fechas.

El modelo parte de dos tablas principales:

• Ventas → qué se vendió, cuándo, dónde y por cuánto.
• Presupuestos → qué ventas estaban previstas.

Y las relacioné con tres tablas que aportan contexto:

• Fecha → día, mes, trimestre y año.
• Productos → producto y categoría.
• Tienda → tienda, ubicación, superficie, empleados, alquiler y población.

Así puedo pasar de una pregunta general, como "¿cuánto hemos vendido?", a otras más concretas como "¿qué tienda está detrás del resultado?" o "¿qué producto está influyendo?", sin tener que reconstruir los datos para cada análisis.

Además, añadí algunas tablas auxiliares para controlar elementos del dashboard, como los selectores de tiendas, productos y categorías, y los rankings Top N. Estas tablas no contienen nuevas ventas: sirven para que el usuario pueda interactuar con el informe sin alterar la estructura principal del modelo.

El objetivo no era construir un modelo complejo por sí mismo, sino tener una base ordenada que permitiera hacer preguntas sobre el negocio y llegar hasta el detalle necesario para responderlas.

04 · DAX

92 medidas, organizadas como código.

A medida que el modelo crecía, también lo hacía el número de medidas necesarias para analizarlo. Llegué a 92 medidas DAX y decidí organizarlas siguiendo una estructura clara, agrupando la lógica para que fuera más fácil localizar, mantener y reutilizar cada cálculo, igual que se organiza un proyecto de código y no una hoja de cálculo.

No se trataba solo de conseguir que las medidas funcionaran. También quería que, si volvía al proyecto después de un tiempo, pudiera entender rápidamente dónde estaba cada cálculo y qué hacía.

05 · Power BI

Del TPV en bruto a un dashboard con drill-down.

El siguiente paso fue llevar el modelo a Power BI y construir una navegación que permitiera pasar de lo general a lo particular. Partí de los datos de TPV y fui construyendo diferentes niveles de análisis para que el usuario pudiera profundizar cuando encontrara una variación relevante. El drill-down se convirtió así en una parte importante del informe: no solo mostrar el dato, sino permitir investigar qué hay detrás.

06 · Usuarios

Trece páginas, cuatro roles distintos.

No todas las personas necesitan consultar la información de la misma manera. Por eso estructuré las 13 páginas del informe teniendo en cuenta diferentes necesidades de análisis y perfiles de usuario. La información cambia según el nivel de detalle que necesita cada persona, pero el modelo y la lógica del análisis se mantienen conectados. Así, el informe funciona como un sistema de reporting y no simplemente como una colección de dashboards independientes.

08 · Páginas del informe

Dos de las trece páginas del informe.

Estas son dos ejemplos de cómo llevé el modelo y la lógica de análisis a Power BI. Cada página responde a una necesidad diferente, pero todas parten de la misma estructura de datos y mantienen una lógica común de navegación. El objetivo fue evitar dashboards aislados y construir un sistema en el que las diferentes vistas se complementaran entre sí.

09 · Qué permite hacer

Qué permite ver el sistema, en un caso concreto.

La utilidad del informe aparece cuando se utiliza para responder preguntas concretas. Por ejemplo, si un KPI muestra una variación, puedo empezar viendo el resultado general, comparar tiendas o categorías y profundizar hasta encontrar qué está provocando el cambio.

El año cerró en 717.304 € frente a un presupuesto de 776.000 €: una desviación de −58.700 € (−7,56 %). La portada del informe reparte esa cifra por tienda: Mahón, la de más ventas de la red (277.000 €), era también la que más arrastraba la desviación (−47.700 €). Sant Francesc Xavier e Ibiza (ciudad), con menos volumen, eran las únicas dos en positivo (+6.000 € y +4.600 €).

Un patrón parecido aparecía por categoría: Bebidas y Refrescos lideraba en ventas y en margen (+37,58 %), mientras Conveniencia y Tienda Express cerraba con margen negativo pese a un volumen similar.

Para mí, esta es una de las partes más interesantes de Power BI: conectar diferentes niveles de información para que el usuario no tenga que empezar de cero cada vez que aparece una pregunta nueva.

Herramientas

Stack técnico

10 · Conclusión

El orden importa.

Trabajar en este proyecto me hizo prestar mucha más atención a lo que ocurre antes de construir un gráfico. Cuando los datos están bien estructurados, las medidas están organizadas y el modelo tiene una lógica clara, es mucho más fácil construir un informe que pueda crecer sin convertirse en un conjunto de elementos difíciles de mantener.

También me ayudó a entender algo que considero importante en Power BI: un buen dashboard no termina cuando encontramos el KPI correcto. La parte interesante empieza cuando podemos preguntar qué hay detrás de ese KPI y tenemos un modelo preparado para encontrar la respuesta.