Proyectos

El Problema

En muchos equipos comerciales el análisis de ventas empieza y termina en el total. Si la cifra sube, todo bien. El problema es que dos períodos pueden cerrar con el mismo número y haber sido radicalmente distintos por dentro: uno con crecimiento real, otro con caída compensada por una campaña puntual. Sin variación integrada en el visual, esa diferencia no se ve.

El Objetivo

Construir un informe de ventas que permitiera leer volumen y variación en una sola lectura, sin necesidad de cruzar pestañas ni comparar tablas separadas. Y hacerlo siguiendo el estándar IBCS, que define cómo representar esa información de forma que cualquier persona lo lea igual, sin ambigüedad.

Mi Enfoque

El estándar IBCS (International Business Communication Standards) establece reglas concretas sobre cómo representar variaciones: qué color indica desviación positiva, qué forma indica valor real frente a presupuesto, cómo se integran volumen y variación en el mismo eje sin que se solapen ni confundan.

Construí tres tipos de visual siguiendo ese estándar. El gráfico de columnas con niveles múltiples permite ver simultáneamente el valor absoluto mensual, la variación absoluta respecto al año anterior y el porcentaje de cambio. El gráfico de columnas con variación integrada compacta esa información dentro de cada barra, útil cuando el eje tiene muchos elementos como productos o categorías. El gráfico de líneas de variación muestra la evolución temporal con el área entre la línea real y el target coloreada según si se supera o no el objetivo.

El modelo vive sobre fact_ventas con cinco dimensiones: Producto, Campaña, Región, Cliente y Calendario. Una tabla adicional IBCS-Selector-Medidas gestiona el cambio dinámico entre Cantidad Total Vendida y Ventas Totales en euros sin duplicar páginas.

Herramientas Utilizadas

Power BI para el modelo, los tres tipos de visual IBCS y la navegación entre vistas. DAX y cálculos visuales en combinación: DAX para las medidas base, el selector dinámico entre Cantidad y Ventas en euros, y el formateo condicional; cálculos visuales para generar las variaciones CY vs SPLY y contra Target directamente sobre cada visual sin multiplicar medidas en el modelo.

Qué Aprendí

Replicar el estándar IBCS en Power BI sin custom visuals obliga a entender bien cómo funciona el formateo condicional a nivel de medida y cómo construir variaciones que se comporten correctamente con cualquier combinación de filtros activa. La parte más exigente fue conseguir que los tres niveles del gráfico de columnas múltiples mantuvieran las proporciones correctas independientemente del rango de valores del filtro seleccionado. También aprendí que seguir un estándar visual no limita el análisis, lo hace más legible para cualquiera que lo reciba.

El Problema

La dirección tenía números delante pero no tenía contexto. Sabían la recaudación del día pero no podían decir qué categorías erosionaban el beneficio, qué tienda estaba por debajo de la media en margen o si estaban cumpliendo objetivos o solo superando el mes anterior. Cada departamento miraba su parte. No existía una fuente única que conectara ventas, rentabilidad y objetivos. Eso no es un problema de datos. Es un problema de estructura analítica.

El Objetivo

Construir un sistema de reporting que permitiera pasar de una desviación en un KPI hasta el ticket concreto que la explica, con ventas, margen y objetivos conectados en el mismo modelo y sin necesidad de cruzar hojas de cálculo separadas.

Mi Enfoque

El error de fondo era el orden en que se había planteado el análisis: vistas parciales sobre datos sin modelar, en lugar de diseñar primero cómo debía funcionar el negocio como modelo. Empecé por ahí. Esquema en estrella con dos tablas de hechos, Ventas y Presupuestos, conectadas a las mismas dimensiones de fecha, tienda, producto, categoría y objetivos. Power Query para transformar y estandarizar los datos brutos del TPV. Tablas de desconexión T_DISC para gestionar los filtros cruzados sin contaminar el modelo. Parámetros TopN para los selectores de categoría y producto.

El sistema tiene cinco vistas: Ventas Anuales muestra el cumplimiento global contra presupuesto y la evolución YTD por tienda. Ranking Tiendas compara ventas, margen y beneficio por tienda y categoría simultáneamente. Ticket Medio analiza el comportamiento de compra a nivel de tienda, producto y día. Comparar KPIs pone en paralelo cualquier tienda contra el resto. Y desde cualquier punto del dashboard es posible hacer drill-down hasta el ticket y el producto que explica la desviación.

Hallazgos Clave

Mahon era la tienda con mayor volumen de ventas (277.000€) pero arrastraba una desviación negativa de 47.700€ respecto al presupuesto. Sant Francesc Xavier, con menos volumen, era la única que cerraba en verde con +6.000€ sobre objetivo. En categorías, Bebidas y Refrescos era la más vendida con 43.500€ y también la que más margen generaba (+37,58%). Conveniencia y Tienda Express cerraba con margen negativo. Dos categorías que visualmente parecen similares en volumen pero que se comportan de forma opuesta en rentabilidad.

Herramientas Utilizadas

Power Query para la transformación y limpieza de los datos del TPV antes del modelo. Power BI para el modelo en estrella y las cinco vistas del dashboard con drill-down hasta nivel de ticket diario. DAX para las medidas de ventas YTD, cumplimiento vs presupuesto, margen por categoría y producto, y ticket medio con comparativa entre tiendas.

Qué Aprendí

El drill-down hasta nivel de ticket fue la parte más exigente del modelo. Para que funcionara correctamente con cualquier combinación de filtros activa, las relaciones entre tablas tenían que estar diseñadas desde el principio con esa granularidad en mente. También aprendí que el orden importa: diseñar el modelo antes que los dashboards no es una preferencia metodológica, es lo que determina si el sistema aguanta o se rompe cuando alguien hace una pregunta que no estaba prevista.

El Problema

El problema habitual en los reportes de marketing es que se compara volumen sin mirar inversión, se analizan clics sin mirar CTR, se celebran conversiones sin analizar su coste. Los KPIs se revisan de forma aislada y eso genera lecturas que llevan a decisiones equivocadas. El reto no era añadir más métricas sino introducir contexto sin añadir ruido: obligar a que cada dato apareciera siempre junto a su referencia.

El Objetivo

Construir un dashboard que respondiera no si las cifras suben o bajan, sino si la inversión está rindiendo mejor o peor que el año anterior, con nueve métricas clave — Impresiones, Alcance, Engagement, Clicks, CTR, Gasto, Conversiones, CPC y Conversiones € — filtradas por plataforma, tipo de post, campaña y mes.

Mi Enfoque

Diseñé el modelo sobre un esquema en estrella con fact_table en el centro y siete dimensiones: Calendario, Plataforma, Contenido, Campaña, TipoPost, Target Audiencia y Boosted. Esta última permite filtrar específicamente por posts impulsados vs orgánicos, una distinción que en análisis de social media cambia completamente la lectura de los datos.

Uno de los puntos menos visibles pero más importantes fue el selector de periodos. En lugar de filtrar directamente el modelo, usé una tabla desconectada (MesCortoSelector) que marca el periodo a analizar. Eso garantiza que los cálculos interanuales sean coherentes con cualquier combinación de filtros activa. Cada KPI se presenta con el mismo marco: valor actual, valor del año anterior, variación absoluta, variación porcentual y un sparkline mensual para detectar tendencia sin necesidad de cambiar de página.

Hallazgos Clave

En mayo de 2025 las impresiones cayeron un 12,8% respecto a 2024 y el alcance un 10,1%. A primera vista, rendimiento peor. Pero el gasto cayó un 26,3%. El CPC pasó de 0,25€ a 0,21€. El negocio estaba generando resultados similares gastando considerablemente menos, lo que significa que la eficiencia mejoró aunque el volumen bajara. Esa lectura no es posible si los KPIs se analizan por separado. Solo aparece cuando inversión y rendimiento están en el mismo marco de referencia.

Herramientas Utilizadas

Power BI para el modelo en estrella, los nueve KPI cards con sparklines integrados y los filtros por plataforma, campaña, tipo de post y periodo. DAX para todas las medidas interanuales: valor actual, valor año anterior, variación absoluta y porcentual. La lógica de comparación año contra año tiene que mantenerse correcta con cualquier filtro de mes activo, lo que requiere medidas de inteligencia de tiempo bien construidas desde el modelo.

Qué Aprendí

La tabla desconectada para el selector de mes fue la decisión técnica que más impacto tuvo en la fiabilidad del modelo. Sin ella, al filtrar por un mes concreto las medidas interanuales devolvían resultados incorrectos porque el filtro afectaba tanto al año actual como al año anterior al mismo tiempo. También aprendí que nueve KPIs en una sola página solo funcionan si el diseño tiene una jerarquía clara. Sin ella, la densidad de información paraliza al usuario en lugar de orientarlo.

El Problema

Cuando cada área analiza su parte por separado, dirección necesita construir la visión completa manualmente cada vez. Ese proceso es lento, poco trazable y genera versiones distintas de la misma realidad. Sin un modelo que conectara los tres estados financieros de forma coherente, cualquier análisis era una foto parcial.

El Objetivo

Diseñar una estructura contable que unificara balance, PyG y cash flow, mantuviera coherencia entre periodos y permitiera navegar desde un KPI de alto nivel hasta el asiento concreto que lo genera, sin salir del informe.

Mi Enfoque

Empecé por el modelo. Dos tablas de hechos: FactDiario con los apuntes contables reales y FactPresupuesto con los datos presupuestados, conectadas a las mismas dimensiones de Calendario, Empresas, Orígenes, CuentasContables y Partners. Cuatro dimensiones adicionales para la jerarquía contable: dimPyG, dimBalance, dimCF y DimApuntes, cada una con su propia estructura de niveles.

Una tabla TablaFechaCierre gestiona la proyección a cierre: permite extrapolar el resultado esperado a fin de año a partir de los datos reales disponibles hasta la fecha de corte, manteniendo la coherencia con el presupuesto original.

El informe tiene seis áreas con navegación: panel de KPIs con EBITDA, ROE, ROA, Test Ácido, Solvencia y Free Cash Flow; checklist de validación que detecta asientos descuadrados y cuentas sin clasificar; balance de sumas y saldos con drill-through hasta el apunte individual; balance general con análisis vertical, horizontal y evolución temporal; PyG con tres vistas (evolución trimestral, comparativa vs presupuesto y proyección a cierre); y cash flow con flujos de explotación, inversión y financiación comparados con el año anterior.

Hallazgos Clave

El checklist de validación fue una de las decisiones más importantes del diseño. En un modelo que consolida varias empresas con distintos orígenes de datos, tener una página dedicada a detectar asientos descuadrados y cuentas 4D sin clasificar antes de navegar al análisis evita que un error contable llegue a una reunión de dirección como si fuera un resultado real. En 2023, el Free Cash Flow fue de 678.208€ frente a –1.165.649€ del año anterior. El modelo permite ver exactamente qué partidas explican esa diferencia.

Herramientas Utilizadas

Power BI para el modelo completo, la navegación entre las seis áreas del informe y el drill-through desde cualquier KPI hasta el apunte contable de origen. DAX para todas las medidas financieras: ratios de solvencia y liquidez, cálculos de EBITDA, variación interanual, desviación vs presupuesto y la lógica de proyección a cierre que combina datos reales hasta la fecha de corte con la extrapolación del resto del ejercicio.

Qué Aprendí

Consolidar varias empresas en un único modelo añade una capa de complejidad que no existe en proyectos de una sola empresa. Las relaciones entre FactDiario y las dimensiones tienen que estar diseñadas para que los filtros por empresa no rompan la coherencia de los totales consolidados. La proyección a cierre fue la pieza técnica más exigente: para que funcione tiene que distinguir entre meses con datos reales y meses sin ellos, y la lógica de extrapolación tiene que ser coherente tanto en la tabla como en el gráfico de evolución temporal.

El Problema

Cuando los datos financieros llegan al BI sin estructura contable detrás, los problemas son predecibles: totales que no cuadran al cambiar el filtro, signos que se invierten según el contexto, subtotales que agregan lo que no deberían. En un informe que dirección usa para tomar decisiones, perder coherencia significa perder credibilidad.

El Objetivo

Construir un P&L que respondiera bien en cualquier escenario: con filtros cruzados por año, trimestre, departamento y organización, con Real vs Presupuesto comparables en el mismo informe, y con subtotales que cuadraran siempre sin depender de parches visuales.

Mi Enfoque

Construí el modelo desde la lógica contable, no desde la visual. Cada cuenta clasificada explícitamente como ingreso, coste o gasto, con reglas de signos definidas a nivel de modelo para que los totales cuadraran en cualquier nivel de filtro. Los subtotales — Margen Bruto, Beneficio Operativo y Beneficio Neto — responden cada uno a su estructura contable concreta, no a una agregación automática.

El modelo vive sobre una tabla de hechos central PyG con seis dimensiones: Calendario, Cuentas, Departamentos, Escenario, Organizaciones y Encabezados. Las medidas están organizadas en seis carpetas: Básico, Importe, Presupuesto, Real, Variación y Tiempo. Sobre esa base construí la comparativa Real vs Presupuesto con variación absoluta, porcentaje de desviación y un waterfall chart que no solo muestra la diferencia sino que explica qué partidas la generan y en qué dirección.

Hallazgos Clave

El dashboard tiene dos vistas. La primera es la PyG expandible con cuatro años de datos (2020–2023), Real y Presupuesto en columnas paralelas, con indicadores visuales de desviación por partida. La segunda es la vista de detalle con el Estado de Resultados Comparativo completo más dos waterfall charts. En 2021 el Beneficio Neto Real fue de 6,78 millones frente a 3,53 millones presupuestados, una desviación positiva del 92,1%. La cascada muestra que el driver principal fue el crecimiento de ingresos, no la contención de costes.

Herramientas Utilizadas

Power BI para el modelo completo, las dos vistas del informe y la navegación entre ellas. DAX para los subtotales con lógica contable, el control de signos, las medidas de variación Real vs Presupuesto y los cálculos de cascada. La medida Beneficio neto cascada es la pieza más compleja del modelo: tiene que mantener coherencia tanto en la tabla como en el waterfall chart con cualquier combinación de filtros activa.

Qué Aprendí

La parte más exigente no fue construir el visual sino garantizar que los signos contables fueran correctos en todo momento. Un ingreso y un coste tienen signos contables distintos que no coinciden con cómo Power BI agrega por defecto. Sin esa lógica resuelta en el modelo, el waterfall chart mostraba números correctos pero con la dirección equivocada. También aprendí que separar las medidas en carpetas temáticas desde el principio no es una preferencia estética: es una decisión que ahorra horas cuando el modelo crece.

El Problema

La mayoría de análisis de mercado turístico trabajan con medias globales. Una media que mezcla San Sebastián en agosto con un municipio interior en enero, un alojamiento completo con una habitación privada, un anfitrión ocasional con uno que gestiona treinta propiedades. Un mismo precio puede parecer caro o barato según el contexto. Sin estructura, los datos no informan.

El Objetivo

Construir un análisis que respondiera una pregunta más útil que "¿es caro?": si un precio elevado responde a alta demanda, a baja oferta, a profesionalización del mercado o a estacionalidad puntual. Y hacerlo partiendo de la dimensión que los análisis habituales ignoran: el territorio.

Mi Enfoque

El mercado turístico no es homogéneo, es espacial antes que estadístico. Diseñé el modelo alrededor de esa premisa: el mapa como eje principal de lectura, con filtros que modifican el patrón espacial en tiempo real según provincia, tipo de alojamiento, rango de precios y disponibilidad mínima.

El modelo vive sobre un esquema en estrella con fact_Listings en el centro y cuatro dimensiones: Localización, TipoHabitación, Host y Calendario. Una dimensión adicional de segmentación de precio clasifica cada propiedad en rangos: Económico, Medio, Alto y Lujo. Sobre esa base construí la segmentación que los análisis habituales omiten: precio por tipo de alojamiento y distinción entre anfitrión ocasional y operador profesional con cartera.

Hallazgos Clave

El 75% de los anfitriones son ocasionales con una sola propiedad. Los operadores profesionales con más de 15 propiedades son solo 31, pero concentran una parte desproporcionada de la oferta en zonas de alta demanda. Bilbao y San Sebastián acumulan el mayor volumen de reseñas mensuales con 428 y 391 respectivamente. El alojamiento completo tiene un precio medio de 211,78€, más del doble que una habitación privada (95,24€). La diferencia no es solo de tipo: son distintos compradores, distintas zonas y distinta estacionalidad.

Herramientas Utilizadas

Power BI para el modelo de datos, los mapas con geolocalización de cada propiedad y el dashboard completo con navegación entre vista de análisis y vista de mapa. DAX para las medidas de precio medio, disponibilidad, clasificación por segmento y la lógica de clasificación de anfitriones por tamaño de cartera.

Qué Aprendí

Trabajar con datos geoespaciales en Power BI tiene más complejidad de la que parece: la calidad del mapa depende directamente de la calidad de las coordenadas y de cómo está modelada la dimensión de localización. También aprendí que la segmentación de precio por rangos es una decisión de diseño tanto como técnica: los cortes tienen que tener sentido para el mercado concreto que estás analizando, no ser percentiles genéricos.

El Problema

El director comercial tenía los números y no los entendía. Revenue cayendo, cartera creciendo. La primera reacción fue buscar más ventas. Pero antes de eso había que confirmar si el problema estaba en la captación o en la retención. Sin una forma de ver el comportamiento real de cada cliente, esa pregunta no tiene respuesta.

El Objetivo

Clasificar a los 400 clientes según su comportamiento real de compra — cuándo compraron por última vez, con qué frecuencia y cuánto — para identificar qué segmentos estaban perdiendo actividad y cuánto revenue había en riesgo real.

Mi Enfoque

Construí un modelo RFM sobre el histórico de pedidos. Cada cliente recibe tres puntuaciones: Recency (días desde la última compra), Frequency (número de pedidos) y Monetary (importe total acumulado). Los cortes no son fijos: se calculan con percentiles dinámicos sobre toda la tabla, lo que hace que el modelo funcione bien con cualquier distribución de datos sin tener que ajustar umbrales a mano. Con esas tres puntuaciones, cada cliente queda asignado a uno de siete segmentos: Champion, Loyal, Potential, At Risk, Needs Attention, Average y Lost.

El modelo vive sobre un esquema en estrella con Fact_Pedidos en el centro y cinco dimensiones: Cliente, Fecha, Producto, Comercial y TipoEstablecimiento. Todas las columnas del RFM, incluidos los tres scores y el segmento final, están en Dim_Cliente. El dashboard responde cuatro preguntas en una sola página: salud del negocio, distribución por segmento, evolución mensual del revenue y acción comercial recomendada para cada grupo — esta última generada como tabla HTML directamente desde una medida DAX.

Hallazgos Clave

El segmento Loyal concentraba 111 clientes y casi la mitad del revenue total. Llevaban meses con la recency creciendo. Más de 198.000€ en clientes que antes compraban bien y que llevaban tiempo sin aparecer. Sin segmentación esa señal se pierde en el total. Con ella tiene nombre, tiene cifra y tiene una acción concreta: reactivar ya. Los Champions eran solo 34 clientes, con recency media de 14 días y un ticket medio de 4.787€. Los más activos y los más rentables, recibiendo el mismo trato que el resto.

Herramientas Utilizadas

Power BI para modelar los datos, calcular el RFM en DAX y construir el dashboard completo con filtros por zona, establecimiento, comercial y año. DAX para los tres scores, la asignación de segmento y la tabla de acciones comerciales. La tabla final se genera como HTML dentro de una medida, sin necesidad de visuals externos.

Qué Aprendí

La parte técnica no fue lo más difícil. Lo complicado fue decidir los cortes de segmentación: cuándo un cliente pasa de Loyal a At Risk no puede ser un número arbitrario, tiene que reflejar el comportamiento real del negocio. Usar percentiles dinámicos en lugar de umbrales fijos fue la decisión que más mejoró la calidad del modelo. Generar una tabla HTML desde DAX también tiene sus limitaciones en Power BI, y esas limitaciones obligan a pensar más en el diseño antes de escribir la primera línea de código.