Antes de que un reporte llegue a la pantalla de un director o se comparta con todo un equipo comercial, alguien tuvo que sentarse a construirlo: conectar los archivos correctos, limpiar columnas que venían con errores, definir cómo se relacionan las tablas entre sí y decidir qué gráfico comunica mejor cada idea. Todo ese trabajo ocurre en Power BI Desktop, antes de que exista cualquier versión publicada o compartida.
Es común que una empresa hable de «usar Power BI» sin distinguir en qué parte del proceso está. Desktop es el taller: ahí se arma el modelo, se transforman los datos y se diseña cada visual. En los diagnósticos que hace ITD Consulting, esta confusión suele ser de las primeras cosas que aclaramos con un cliente nuevo. Lo que pasa después —publicar, compartir, actualizar automáticamente— ocurre en otra capa de la misma familia de herramientas. Confundir ambas partes lleva a expectativas equivocadas, como pensar que instalar Desktop en una computadora ya resuelve la distribución del reporte a todo un equipo.
Power BI Desktop se instala de forma gratuita y no requiere licencia para construir un modelo completo: conectar datos, transformarlos, definir relaciones y diseñar visuales no tiene costo. La necesidad de una licencia aparece más adelante, cuando se quiere compartir ese trabajo con otras personas dentro de una plataforma centralizada, generalmente conectada al mismo entorno de Microsoft 365 que la empresa ya utiliza para correo y documentos.
En ITD Consulting pasamos buena parte de cada proyecto trabajando directamente en Desktop: ahí es donde se decide si un modelo de datos va a ser sólido y fácil de mantener, o si va a generar dolores de cabeza en cuanto la empresa necesite agregar una fuente nueva o cambiar un cálculo.
Un archivo de Power BI Desktop no es solo una colección de gráficos: es un modelo de datos completo, con sus propias reglas de transformación, sus relaciones entre tablas y sus cálculos definidos. Ese modelo es la base sobre la que después se apoya cualquier visual, y su calidad determina qué tan confiable es todo lo que se construye encima.
El trabajo dentro de Desktop suele responder preguntas muy concretas antes de llegar al diseño visual:
Nada de esto se resuelve arrastrando un gráfico al lienzo de diseño ni eligiendo un color bonito para la portada. Se resuelve antes, con las herramientas de transformación y modelado, en la parte menos visible del trabajo, que es justamente donde se define si el resultado final va a ser confiable.
Invertir en construir bien el modelo desde Desktop, antes de pensar en cómo se va a compartir después dentro de Microsoft 365, evita ese tipo de fragilidad. Un modelo bien construido permite:
El tiempo que se dedica a modelar bien casi siempre se recupera más adelante, en forma de menos correcciones urgentes y menos reportes que dejan de funcionar apenas algo en la empresa cambia.
Casi nadie llega a pedirnos ayuda porque Power BI Desktop no sirva. Llega porque construyó algo rápido en algún momento, y ese algo ya no aguanta el peso de cómo creció la empresa. Estos son los cuatro problemas más comunes.
Cuando cada gráfico define su propia fórmula en lugar de apoyarse en una medida centralizada, es cuestión de tiempo hasta que dos visuales del mismo reporte muestren cifras que no coinciden entre sí. Centralizar los cálculos dentro del modelo, en lugar de repetirlos, resuelve este problema de raíz.
Muchos archivos se arman pensando únicamente en la fuente de datos que existía en ese momento. Cuando aparece una fuente nueva —una sucursal más, un sistema adicional— el modelo no tiene espacio para incorporarla sin rehacer buena parte del trabajo original.
Sin usar bien las herramientas de transformación de Power Query dentro de Desktop, es común terminar limpiando los mismos datos manualmente cada vez que se actualiza el archivo, en lugar de dejar ese proceso automatizado una sola vez dentro del modelo.
Un modelo mal optimizado —con columnas innecesarias, cálculos ineficientes o demasiados datos sin resumir— se vuelve cada vez más lento de abrir y actualizar. Con el tiempo, esto desanima a que el equipo lo use con la frecuencia que debería. Por ejemplo:
Resolver estos cuatro problemas desde el modelo, no desde el diseño visual, es lo que distingue un archivo de Power BI que sigue funcionando bien un año después de otro que hay que reconstruir cada pocos meses. Es también, casi siempre, el motivo real detrás de un proyecto de reconstrucción que emprendemos en ITD Consulting.
Conocer estas piezas por su nombre facilita conversar sobre el modelo con quien lo construyó, y detectar más rápido en cuál de ellas está el problema cuando algo no cuadra.
Es el motor de transformación dentro de Desktop: permite quitar columnas innecesarias, corregir formatos, combinar archivos y dejar los datos listos antes de que lleguen al modelo. Cada paso queda registrado, así que si la fuente cambia, la transformación se puede volver a aplicar sin repetir el trabajo manual.
Las medidas construidas con DAX son las que permiten ir más allá de una suma simple: comparaciones contra el año anterior, porcentajes de cumplimiento, promedios móviles. Dominar lo básico de este lenguaje es lo que separa un reporte que solo muestra datos de uno que realmente calcula algo útil.
Una vez que los datos están limpios, hay que definir cómo se relacionan: qué tabla de ventas se conecta con qué tabla de productos, y bajo qué criterio. Un modelo de relaciones bien pensado es lo que permite que un solo filtro afecte correctamente a todos los visuales relacionados, sin resultados inconsistentes.
Es la parte más visible del trabajo, pero depende por completo de que las tres piezas anteriores estén bien resueltas. Un buen diseño visual sobre un modelo mal construido sigue siendo, en el fondo, un reporte poco confiable.
El tipo de modelo que conviene construir cambia según qué información maneja cada área y qué tan compleja es su realidad de datos.
Suele requerir combinar información de distintas fuentes —un CRM, hojas de cálculo de seguimiento, datos de facturación— en un modelo que permita ver el proceso comercial completo, desde el primer contacto hasta el cierre, sin perder el detalle por vendedor o por cliente.
Aquí el modelo exige más cuidado en las fórmulas: un cálculo de margen o de flujo de caja mal definido en Desktop se replica en todos los reportes que dependan de esa medida, incluso una vez publicados dentro de Microsoft 365. Vale la pena invertir tiempo extra en validar estas fórmulas antes de dar el modelo por terminado.
El reto suele estar en combinar datos que rara vez viven juntos: nómina, evaluaciones de desempeño, procesos de contratación. Un modelo bien relacionado permite cruzar esta información sin depender de exportar y unir archivos manualmente cada vez.
Frecuentemente involucra volúmenes de datos más grandes —movimientos de inventario, registros de producción— donde la eficiencia del modelo importa especialmente: un archivo mal optimizado en esta área puede volverse lento de forma notoria conforme crecen los datos.
Antes de diseñar un solo gráfico, dedicamos tiempo a construir bien lo que no se ve: el modelo de datos que va a sostener todo lo demás.
En ITD Consulting revisamos de dónde va a salir la información, qué tan confiable es y qué transformaciones necesita antes de entrar al modelo. Casi siempre aparecen columnas con formatos distintos entre archivos, valores en blanco sin explicación, o cifras que un archivo calcula distinto que otro para el mismo concepto.
En cada proyecto, definimos cómo se van a conectar las distintas tablas, pensando no solo en la necesidad actual sino en qué tan fácil será agregar una fuente nueva más adelante sin rehacer la estructura completa.
Desarrollamos los cálculos centralizados que van a alimentar los visuales, evitando que cada gráfico defina su propia fórmula por separado y generando así resultados consistentes en todo el reporte.
Solo cuando el modelo está bien resuelto pasamos al diseño de los visuales, sabiendo que lo que se construya encima va a ser confiable y fácil de mantener con el tiempo.
El trabajo hecho en Desktop está pensado para publicarse después. Una vez que el modelo y el diseño están listos, ese archivo se sube a la plataforma en la nube, donde se conecta con las cuentas y los permisos que la empresa ya administra, y donde el equipo completo puede consultarlo sin necesidad de tener Desktop instalado.
Esto le da sentido a construir bien desde el principio: un modelo ordenado en Desktop se traduce en un reporte fácil de actualizar automáticamente una vez publicado, mientras que un modelo improvisado arrastra sus problemas a cualquier plataforma donde termine.
Una vez que el modelo está resuelto, Power BI Desktop ofrece varias herramientas para que el reporte final se sienta menos como una hoja de cálculo con gráficos y más como una aplicación pensada para quien la va a usar.
Permiten guardar el estado exacto de una vista —qué filtros están activos, qué página se muestra— para poder saltar entre distintos escenarios con un clic, algo especialmente útil al presentar un reporte en una reunión en lugar de navegarlo en vivo desde cero.
Cuando varias áreas de la empresa necesitan un tipo de reporte similar, definir una plantilla con la estructura y el estilo ya resueltos ahorra horas de diseño repetido y mantiene una identidad visual consistente entre distintos equipos, incluso cuando el archivo final termine compartido dentro de Microsoft 365.
Se puede configurar qué detalle adicional aparece cuando alguien pasa el cursor sobre un dato específico, sin saturar la vista principal con información que no todos necesitan ver todo el tiempo.
Es posible construir una navegación propia dentro del reporte, con botones que llevan de una sección a otra, acercando la experiencia a la de una aplicación diseñada a medida más que a la de un archivo estático. En ITD Consulting solemos incluir este tipo de navegación en reportes que van a usar personas con perfiles distintos, para que cada quien encuentre su vista sin depender de instrucciones adicionales.
Antes de publicar un reporte en la plataforma en la nube, muchas empresas ya colaboran sobre el archivo dentro de Microsoft 365: guardándolo en una carpeta de SharePoint o de OneDrive donde más de una persona puede acceder a la versión más reciente, aunque la edición simultánea completa quede reservada para una vez que el contenido vive publicado. Coordinar bien este paso intermedio evita la confusión de tener el mismo archivo copiado en varias carpetas distintas, cada una con una versión ligeramente diferente del modelo.
Estas son las prácticas que marcan la diferencia entre un archivo que sigue siendo manejable con el tiempo y uno que se vuelve difícil de tocar.
Un cálculo llamado «Medida2» no le dice nada a nadie, ni siquiera a quien lo escribió, seis meses después. Nombrar cada elemento según lo que realmente representa ahorra tiempo cada vez que alguien necesita entender o modificar el modelo.
Cargar columnas o tablas completas «por si acaso» infla el tamaño del archivo y ralentiza su funcionamiento sin aportar ningún valor real al reporte final.
Cuando un paso de Power Query involucra una lógica poco evidente, dejar una nota breve sobre qué hace y por qué evita que, más adelante, alguien tenga que descifrar esa lógica desde cero.
Un modelo que funciona bien con datos de ejemplo puede comportarse distinto con el volumen y las particularidades de la información real de la empresa. Validar con datos reales antes de la entrega evita sorpresas después de publicado.
Agregar un nuevo indicador deja de ser un proyecto aparte y se convierte en un ajuste rápido sobre una base que ya existe. El archivo se abre y se actualiza en segundos, no en minutos, porque no está cargando información innecesaria. Y cuando alguien más del equipo necesita modificar el reporte, puede entender la lógica sin depender de que la persona original se lo explique paso a paso.
Nada de esto depende de dominar cada función avanzada de la herramienta. Depende de dedicar el tiempo suficiente al modelo antes de pasar al diseño visual, que es precisamente la parte del trabajo que más se salta cuando hay presión por entregar algo rápido, y precisamente donde más valor aporta el acompañamiento de ITD Consulting en un proyecto nuevo.
No. Se puede descargar e instalar sin costo, y permite construir modelos de datos completos, hacer transformaciones y diseñar reportes sin límite. El costo aparece cuando se quiere publicar ese trabajo en la plataforma en la nube para compartirlo con otras personas.
Desktop es donde se construye el modelo y se diseña el reporte, instalado en una computadora. La plataforma en la nube es donde ese trabajo se publica, se comparte con otras personas y se actualiza automáticamente sin depender de que alguien abra el archivo original.
No para lo básico: conectar datos y crear visuales se puede hacer sin escribir código. Para cálculos más avanzados sí conviene aprender lo esencial del lenguaje DAX, aunque no es necesario dominarlo por completo para construir reportes útiles.
Depende más de qué tan bien optimizado esté el modelo que del tamaño en sí. Un archivo con transformaciones eficientes y solo los datos necesarios puede manejar volúmenes considerables sin volverse lento, mientras que uno mal construido puede tener problemas incluso con relativamente poca información.
Power BI Desktop no está pensado para edición simultánea como un documento colaborativo. Lo habitual es que una persona mantenga el modelo principal, y que los cambios se coordinen para evitar que dos versiones distintas del mismo archivo entren en conflicto.
Una variedad amplia: archivos Excel, bases de datos, sistemas ERP, servicios en la nube y muchas otras plataformas empresariales. La mayoría de las fuentes que una empresa usa habitualmente tienen un conector directo disponible dentro de la herramienta.
No necesariamente, si el modelo se construyó pensando en esa posibilidad. Cuando las transformaciones y relaciones están bien estructuradas, ajustar una fuente suele requerir cambios puntuales, no una reconstrucción completa desde cero.
Con bastante frecuencia: suele recibir actualizaciones mensuales con nuevas funciones y mejoras. Mantener la versión actualizada evita quedarse sin acceso a capacidades que facilitan el trabajo de modelado y diseño.
Depende del alcance. Para reportes simples, un equipo puede aprender lo básico con relativa rapidez. Para modelos más complejos, que van a sostener varias áreas de la empresa y crecer con el tiempo, contar con experiencia especializada desde el diseño inicial evita construir sobre una base que después haya que corregir.
Empezamos revisando el modelo existente para identificar qué partes conviene conservar y cuáles están generando los problemas actuales, ya sea lentitud, cálculos inconsistentes o dificultad para mantenerlo. A partir de ese diagnóstico, reconstruimos lo necesario sin necesariamente partir de cero, y dejamos una base más sólida para lo que la empresa necesite construir después. También, te ofrecemos soporte completamente en español para clientes en países como Argentina, Bolivia, Chile, Colombia, Costa Rica, Ecuador, El Salvador, España, Guatemala, Honduras, México, Nicaragua, Panamá, Paraguay, Perú, Uruguay y Venezuela.
EN 
ES