Casi ningún dato llega listo para analizarse. Llega con columnas de más, fechas guardadas como texto, nombres escritos de tres formas distintas para la misma persona, y filas vacías que nadie recuerda por qué existen. Antes de que cualquier gráfico o cálculo tenga sentido, alguien tiene que limpiar y ordenar esa información. Ese trabajo, dentro de Power BI, ocurre en Power Query.
Dentro de Power BI, ese trabajo de limpieza vive en un espacio propio: el editor de Power Query, donde se conectan las fuentes, se corrigen inconsistencias, se cruzan archivos distintos y se deja todo en condiciones de entrar al modelo. No es la parte más vistosa de un proyecto —nadie presenta una transformación de datos en una reunión ejecutiva— pero es la que determina si todo lo que se construye después va a ser confiable o va a arrastrar errores silenciosos.
Es habitual encontrar equipos que hacen esta limpieza a mano, cada vez que llega un archivo nuevo: borrar columnas, corregir un formato de fecha, quitar espacios en blanco. Cuando ITD Consulting revisa un modelo por primera vez, este patrón repetitivo suele saltar a la vista de inmediato. Power Query existe precisamente para dejar de repetir ese trabajo: cada paso de limpieza se define una sola vez y se vuelve a aplicar automáticamente cada vez que los datos se actualizan, sin que nadie tenga que recordarlo ni repetirlo manualmente.
En ITD Consulting invertimos tiempo importante en esta etapa de cada proyecto, porque un modelo construido sobre datos mal preparados hereda esos problemas sin importar qué tan bien diseñado esté el reporte final.
La función de Power Query no es «hacer bonitos los datos», es dejarlos en una forma que se pueda analizar de manera confiable y que se pueda repetir sin esfuerzo cada vez que cambian.
Estas son algunas de las decisiones que hay que resolver antes de que cualquier dato llegue a un modelo o un reporte:
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.
Es tentador pensar que basta con conectar un archivo y empezar a construir visuales directamente. Funciona mientras los datos llegan perfectos, algo que casi nunca ocurre en la práctica real de una empresa. En cuanto aparece una inconsistencia —un formato distinto, una columna que cambió de nombre, un archivo con una fila adicional que no debería estar ahí— la falta de un proceso de limpieza bien construido se nota de inmediato.
Invertir en construir bien las transformaciones desde el principio le permite a una empresa:
El tiempo invertido en dejar bien resuelta esta etapa se recupera cada vez que se actualiza el modelo, en lugar de tener que revisar manualmente si todo sigue en orden.
Las consultas que recibimos casi nunca son porque Power Query se haya quedado corto como herramienta. Son porque, en algún momento, alguien armó una limpieza suficiente para salir del paso, y esa solución ya no resiste el volumen o la variedad actual de los datos.
Cuando una transformación se construye pensando únicamente en el archivo que existía en ese momento, cualquier cambio en el origen —una columna renombrada, un formato distinto— puede romper todo el proceso, obligando a reconstruirlo en lugar de solo ajustarlo.
Sin transformaciones bien definidas, es común terminar corrigiendo los mismos errores cada mes: mismos formatos de fecha, mismos espacios en blanco, misma columna que hay que eliminar. Ese tiempo, sumado a lo largo del año, suele ser mayor de lo que parece en el momento.
Combinar dos fuentes con el criterio equivocado puede multiplicar filas silenciosamente, inflando totales sin ningún mensaje de error visible. Este tipo de error rara vez se anuncia solo: alguien tiene que notar, casi por casualidad, que un total no cierra como debería.
Cuando una transformación se construye a fuerza de prueba y error, sin un criterio claro, termina siendo una secuencia de pasos difícil de seguir para cualquier persona distinta a quien la armó. Por ejemplo:
Resolver estos cuatro problemas desde el diseño de la transformación, no parchando cada error conforme aparece, es lo que distingue un proceso de datos que sigue funcionando con el tiempo de uno que colapsa apenas algo cambia.
Entender estos conceptos ayuda a construir procesos de limpieza más sólidos desde el principio, en lugar de resolver cada problema de forma aislada conforme aparece.
Son los puentes que permiten traer información desde distintos orígenes: hojas de cálculo, sistemas de gestión empresarial, plataformas en la nube, sitios web y decenas de otros formatos posibles. Elegir el conector adecuado desde el principio ahorra complicaciones más adelante, sobre todo cuando llega el momento de programar una actualización automática.
Cada acción de limpieza —quitar una columna, cambiar un tipo de dato, filtrar filas— queda registrada como un paso independiente y visible, en el orden en que se aplicó. Esto permite revisar, reordenar o corregir un paso específico sin tener que rehacer todo el proceso desde cero.
Combinar une columnas de dos tablas distintas según una relación entre ellas, mientras que anexar apila filas de tablas con la misma estructura, una debajo de otra. Confundir estas dos operaciones es una fuente frecuente de resultados inesperados.
Cada paso visual que se aplica en Power Query genera, por debajo, una línea de código en un lenguaje llamado M. No hace falta escribirlo directamente para la mayoría de los casos, pero entender que existe ayuda a resolver transformaciones más complejas que la interfaz visual no cubre del todo.
Permiten definir valores reutilizables —una ruta de archivo, un rango de fechas— que se pueden ajustar en un solo lugar en vez de modificar el proceso completo cuando algo cambia, como al pasar de un entorno de pruebas a uno de producción.
Detectar y corregir estos cuatro problemas suele requerir revisar no solo la fórmula en sí, sino todo el modelo de relaciones que la rodea, porque en DAX el resultado de un cálculo depende tanto de la fórmula como del contexto en el que se evalúa.
El tipo de transformación que más se necesita cambia según qué tan desordenados llegan los datos de cada área y cuántas fuentes distintas hay que combinar.
Suele requerir combinar información de un sistema de ventas con hojas de seguimiento manual y datos de marketing, unificando nombres de clientes o productos que rara vez coinciden exactamente entre un sistema y otro.
Aquí la limpieza exige especial cuidado con los formatos numéricos y las fechas, porque un error de tipo de dato en una cifra financiera puede pasar completamente desapercibido hasta que alguien nota que un total no cuadra con lo que ya validó contabilidad, incluso después de que el reporte ya circula dentro de Microsoft 365.
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 construir cualquier modelo o reporte, revisamos con detalle cómo llegan realmente los datos, no cómo deberían llegar en un escenario ideal.
Revisamos cada archivo o sistema de origen para identificar inconsistencias reales: formatos mezclados, columnas con nombres inconsistentes, información duplicada o incompleta que nadie había detectado antes.
En cada proyecto, construimos cada paso pensando en qué pasaría si la fuente cambia ligeramente —una columna nueva, un archivo con más filas— para que el proceso siga funcionando sin necesidad de reconstruirlo por completo.
Dejamos identificado qué hace cada transformación y por qué se construyó de esa manera, para que cualquier persona del equipo pueda revisar o ajustar el proceso sin depender de quien lo armó originalmente.
Probamos el proceso completo con el volumen real de información que maneja la empresa, no solo con un archivo pequeño de prueba, para detectar a tiempo cualquier paso que se comporte distinto a gran escala.
La diferencia entre limpiar datos «una vez» y construir un proceso de transformación real está en la repetibilidad. Un archivo limpiado a mano resuelve el problema de ese momento específico; un proceso bien construido en Power Query resuelve el mismo problema cada vez que llegan datos nuevos, sin que nadie tenga que intervenir.
Esta diferencia se vuelve más evidente con el tiempo: una empresa que solo limpia datos de forma manual ve crecer ese esfuerzo cada mes, mientras que una que invirtió en construir bien el proceso ve ese mismo trabajo reducirse a revisar que la actualización automática se haya completado sin errores.
Uno de los aspectos menos visibles de Power Query, pero con más impacto en el rendimiento, es el plegado de consultas: la capacidad de traducir los pasos de transformación en instrucciones que el sistema de origen ejecuta directamente, en lugar de traer todos los datos primero y procesarlos después dentro de Power BI.
Cuando esto ocurre, filtrar una tabla de un millón de filas para quedarse con mil puede resolverse en el propio origen, trayendo solo esas mil filas, en vez de descargar el millón completo y filtrar después. La diferencia en tiempo de actualización puede ser enorme, especialmente con fuentes como bases de datos que sí permiten este tipo de traducción.
No todos los pasos de transformación se pueden plegar de esta manera, y algunas operaciones —como ciertas combinaciones complejas o transformaciones de texto muy específicas— rompen esa posibilidad incluso si los pasos anteriores sí la aprovechaban. Por eso, al construir procesos de este tipo en ITD Consulting, prestamos atención al orden de los pasos, dejando primero los que sí se pueden plegar y dejando para el final aquellos que necesariamente van a procesarse dentro de Power BI.
Cuando una tabla crece constantemente —transacciones diarias, por ejemplo— actualizar todo el historial completo cada vez es un desperdicio de tiempo y recursos. La actualización incremental permite definir que solo se vuelva a procesar la información reciente, dejando intacto el resto del historial ya cargado previamente.
Configurar esto correctamente requiere pensar con cuidado en los parámetros de fecha y en cómo el modelo distingue qué es «nuevo» de lo que ya está cargado, pero el beneficio es considerable: un proceso que antes tomaba varias horas puede reducirse a minutos una vez implementado correctamente, algo especialmente valioso para modelos que se actualizan varias veces al día dentro de Microsoft 365.
Con estas costumbres, un proceso de limpieza se mantiene entendible incluso después de que crece y se le agregan pasos nuevos con el tiempo.
Un paso llamado «Cambiar tipo1» no le dice nada a nadie más adelante. Renombrar cada paso según su propósito real —por ejemplo, «corregir formato de fecha de ventas»— facilita entender el proceso completo de un vistazo.
Eliminar filas o columnas innecesarias en los primeros pasos, en lugar de dejarlas hasta el final, reduce la cantidad de datos que el resto del proceso tiene que manejar, con un efecto directo en la velocidad de toda la transformación.
Es común, con el tiempo, terminar con varios pasos que corrigen el mismo tipo de problema de formas distintas. Revisar y consolidar estos pasos periódicamente mantiene el proceso más simple y fácil de seguir.
Cuando la fuente de datos cambia aunque sea ligeramente, conviene ejecutar el proceso completo de nuevo y revisar que cada paso siga comportándose como se espera, en lugar de asumir que todo va a seguir funcionando igual.
Actualizar el modelo deja de ser un momento de tensión, porque el proceso ya sabe qué hacer con los datos nuevos sin intervención manual. Agregar una fuente adicional se vuelve un ajuste puntual sobre un proceso existente, en lugar de un proyecto que empieza desde cero.
La confianza en los números también cambia de naturaleza: con una limpieza documentada y consistente, resulta mucho más fácil distinguir si un número raro refleja algo real del negocio o un tropiezo en cómo se preparó la información, en lugar de sospechar del reporte completo.
Nada de esto requiere conocer de memoria cada opción de transformación disponible en el menú. Depende de entender bien el flujo completo, desde que un dato entra hasta que queda listo para el modelo, que es precisamente el punto donde más ayudamos a los equipos en ITD Consulting durante la etapa inicial de un proyecto.
Es el motor de transformación de datos dentro de Power BI, donde se conectan las fuentes de información, se corrigen inconsistencias y se prepara todo antes de que llegue al modelo. Se usa siempre antes de construir cálculos o visuales, porque la calidad de esa preparación afecta todo lo que viene después.
Para la mayoría de las transformaciones, no: la interfaz permite aplicar pasos de limpieza sin escribir código. Para casos más avanzados existe el lenguaje M, que corre por debajo de cada paso visual, pero no es indispensable dominarlo para resolver la mayoría de las necesidades comunes.
Combinar une columnas de dos tablas relacionadas entre sí, agregando información adicional a cada fila existente. Anexar apila filas de tablas con estructura similar, una debajo de otra, aumentando la cantidad de registros en lugar de columnas. Elegir la operación equivocada suele generar resultados muy distintos a los esperados.
Depende de cómo se construyó el proceso. Si las transformaciones se diseñaron pensando en esa posibilidad, ajustar un paso puntual suele bastar. Si el proceso se construyó de forma rígida, un cambio en el origen puede romper varios pasos a la vez y requerir más trabajo de corrección.
En gran medida, sí. Una vez que el proceso está bien definido, se ejecuta automáticamente cada vez que se actualizan los datos, sin necesidad de repetir manualmente los mismos pasos. Los ajustes solo son necesarios cuando cambia algo estructural en la fuente original.
Puede manejar volúmenes considerables, aunque el rendimiento depende de qué tan eficientes sean los pasos aplicados y, en algunos casos, de si la fuente permite delegar parte del procesamiento al sistema de origen en lugar de traer todos los datos primero.
Conviene construir una consulta base con esa limpieza común y que las demás partan de ella, en lugar de repetir los mismos pasos en cada una. Esto evita corregir el mismo error varias veces si algo cambia más adelante.
El motor es el mismo lenguaje y concepto en ambas aplicaciones, aunque la forma de acceder a él varía ligeramente entre una y otra. Aprender a usarlo en un entorno facilita bastante trasladar ese conocimiento al otro.
Si el proceso es lento o el volumen de datos sigue creciendo, sí. Una transformación que hoy tarda unos segundos puede volverse un cuello de botella real conforme aumenta la cantidad de información, así que revisar su eficiencia antes de que se vuelva un problema suele ahorrar dolores de cabeza después.
Por aislar en qué paso específico ocurre la falla, en lugar de dar por hecho que hay que rehacer todo desde el inicio. Muchas veces el problema está concentrado en uno o dos pasos frágiles, no en el proceso completo. Reforzamos esos puntos, dejamos el resto documentado, y verificamos que la actualización se ejecute sin intervención manual antes de dar el trabajo por cerrado. De igual forma, te brindamos soporte 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