
En este artículo
Power BI es la plataforma de Business Intelligence de Microsoft. Conecta fuentes de datos (ERP, CRM, Excel, bases SQL, APIs, servicios cloud), permite transformarlos y modelarlos, y publica dashboards interactivos que tu equipo consulta en el navegador, en Teams o en el móvil.
Hasta aquí, cualquier proveedor de BI hace lo mismo. Lo que distingue a Power BI en la práctica son cuatro cosas muy concretas: precio por usuario, integración con Microsoft 365, motor de cálculo DAX y la comunidad de usuarios y consultores disponibles. La primera es la que más cierra ventas; la tercera es la que más explica fracasos de proyecto.
Si estás comparando con Tableau o Looker, la comparativa detallada — funcionalidades, precio por usuario, casos donde cada uno gana — está en Power BI vs Tableau vs Looker. Si vienes de Excel y estás pensando en dar el salto, conviene leer antes Excel vs Power BI: cuándo vale la pena cambiar.
Este es el punto donde más empresas se atascan, y donde los pitches comerciales son más confusos. Vamos al grano con los precios vigentes en Microsoft España:
La regla que aplicamos nosotros para PYMEs: empieza con Pro. Si en algún momento justificas con un caso concreto que PPU o Fabric aportan funcionalidad que necesitas, subes. No al revés. Hemos visto empresas pagar 260€/mes de una F2 durante un año entero para un workspace que Pro habría soportado sin pestañear.
Detalle fino que ahorra sustos: los usuarios viewers dentro de una capacidad Fabric/Premium no necesitan Pro individual. Para un workspace con muchos consumidores de dashboards y pocos creadores, esa diferencia cambia el TCO por completo.
DAX (Data Analysis Expressions) es el lenguaje de cálculo de Power BI. Se parece a las fórmulas de Excel, pero no es Excel en otro formato — y confundirlo con Excel es el origen de la mayoría de los problemas que vemos.
La diferencia clave está en un concepto llamado contexto. Una fórmula en Excel opera sobre una celda y es lineal; una medida DAX opera sobre un conjunto de filas que depende del filtro que el usuario haya aplicado en el dashboard en ese momento. La misma medida Total Ventas = SUM(Facturas[Importe]) devuelve cosas distintas cuando el usuario filtra por zona Norte, por trimestre 3 o por cliente concreto — porque el contexto de filtro ha cambiado.
Esto suena abstracto hasta que ocurre el problema típico: el total general no cuadra con la suma de los subtotales. La razón casi siempre es una confusión entre contexto de fila (cuando iteras sobre una tabla) y contexto de filtro (cuando agregas). La función CALCULATE añade una capa más porque modifica filtros explícitamente, y es la fuente habitual del 80% de los bugs en modelos intermedios.
No hace falta ser experto en DAX para empezar. Hace falta saber que DAX es distinto de Excel, tener a alguien en el equipo que haya pasado la curva de aprendizaje, y revisar los totales antes de publicar un dashboard a dirección.
Después de varias implementaciones de Power BI en PYMEs, los errores se repiten. No porque la gente sea torpe — porque son trampas conceptuales que no saltan hasta que ya estás dentro.
1. Modelo plano en lugar de esquema en estrella. Importar una tabla gigante (un export del ERP con 40 columnas) directamente a Power BI funciona al principio y se rompe cuando añades más datos. El modelo correcto separa tablas de hechos (transacciones, facturas, pedidos) de tablas de dimensiones (clientes, productos, fechas), con relaciones one-to-many bien definidas. Es la diferencia entre un dashboard que se puede mantener y uno que hay que rehacer al cabo de seis meses.
2. No marcar la tabla como tabla de calendario. Si quieres usar funciones de time intelligence (DATESYTD, SAMEPERIODLASTYEAR, DATEADD), necesitas una tabla de fechas explícita marcada como calendario en el modelo. Si no la marcas, las funciones no fallan visiblemente — simplemente devuelven resultados incorrectos. Es uno de los errores más sigilosos y más caros.
3. Row-Level Security (RLS) mal configurada. En el momento que un comercial de la zona Norte ve los datos de la zona Sur, tienes un problema grave. RLS se configura con expresiones DAX sobre roles, y si el modelo tiene relaciones many-to-many no resueltas, las reglas de seguridad filtran de forma distinta a lo que esperas. Hay que testarlo con usuarios reales antes de publicar.
4. Direct Query sobre tablas muy grandes. Direct Query (consulta directa contra la fuente, sin importar datos) suena atractivo porque evita el refresco, pero golpea el límite de 1 millón de filas por visual de Power BI. Si tu fact table tiene 30 millones de filas, un visual simple puede truncar resultados sin avisar. Para esos volúmenes, el camino correcto es Import Mode con incremental refresh o Direct Lake en Fabric.
5. El dashboard con 47 gráficos. El más común. El equipo técnico quiere demostrar todo lo que Power BI puede hacer y construye una página con 12 pestañas y 47 visualizaciones. Nadie lo usa. El CFO vuelve al Excel del lunes. Este error lo desarrollamos con detalle en el dashboard financiero que necesita tu CFO; vale para cualquier dashboard, no solo el financiero.
Encaja bien cuando:
Encaja peor cuando:
Instalar Power BI es el 20% del trabajo. El otro 80% es tener los datos integrados, una definición consistente de las métricas, una persona que interprete los resultados y un proceso de gobernanza mínimo que evite que cada departamento genere su propia versión de la verdad.
Sobre cómo estructurar ese trabajo previo — decisiones que tienes que tomar antes de abrir Power BI — hemos escrito el recorrido completo en cómo preparar tu empresa para un proyecto de datos.
¿Estás evaluando Power BI y tienes dudas sobre qué licencia necesitas de verdad, o cómo evitar los cinco errores de arriba? Cuéntanos tu caso y te damos una recomendación concreta en una sesión de 30 minutos.
// escrito por
Director de 480 Analytics
En 480 Analytics, la unidad de datos de Cuatroochenta, ayuda a empresas a ordenar y explotar sus datos con Power BI, Microsoft Fabric e IA. Escribe sobre lo que aprende por el camino.
Te lo cuantificamos. Empezamos por descubrir y ordenar tus datos, y los convertimos en decisiones — empezando por el reporting financiero (FP&A).