Procesar datos, visualizarlos y tomar decisiones… sí, eso ya lo sabemos; pero en realidad…

¿Qué oculta este programa que no es tan evidente?

Veamos:

Es un motor

Power BI Desktop, corre internamente una instancia de SQL Server Analysis Services Tabular. Más allá de verlo envuelto como si fuese un caramelo anaranjado, con la capacidad de conectarse a multiples fuentes de datos y generar visualizaciones; en realidad, estas accediendo a la última generación de motores analíticos que ofrece Microsoft para el procesamiento de datos.

Estamos hablando de un cambio de paradigma en la distribución desde mediados del 2015, dándole la oportunidad de descargarlo de manera «gratuita» a cualquier persona. Y, eso, –para que tengas una idea de cómo el Software como Servicio (SaaS) ha cambiado la adopción en medios de consumo-; representa un costo cero (0), en comparación a inversiones económicas importantes, y conocimientos técnicos que debía tenerse en el pasado para utilizar motores equivalentes.

Ahora, con la premisa de la Analítica de Autoservicio o Self-Service BI el objetivo es democratizar el acceso a este tipo de herramientas; pero con la responsabilidad de no olvidarse de la gobernancia para que no se convierta en anarquía aplicada a los datos.

Se encuentra en Excel

A decir verdad, las primeras versiones del motor son mucho más antiguas porque ya existía como complemento de Excel 2010 –lo que pasa es que a muy pocas personas- les intereso cambiar sus rutinas en la hoja de cálculo por algo llamado Power Pivot; siendo su principal diferenciador la capacidad de superar los límites de filas (1.048.576), un nuevo lenguaje llamado DAX y, la oportunidad crear modelos relacionales.

Congelado a mediados de 2017, sigue estando disponible hoy en día; pero con la ebullición de Power BI Desktop son muy pocas las circunstancias que justifiquen crear un modelo analítico desde Excel. Asimismo, las integraciones que se están llevando a cabo entre ambos programas hará que cada día sea más fácil trasladar el procesamiento a gran escala de los modelos tabulares hacia las hojas de cálculo.

La interrogante que deberá responderse:  ¿Qué proporción de mis datos deben ser procesados por los modelos analíticos, y qué otro en las hojas de cálculo? 

Al comprender que todo se trata de procesamiento, es cuando se comienza a desarrollar una estrategia de adopción, y combinar lo mejor de ambos mundos.

Mezclar datos

El concepto del programa es conectarse a multiples fuentes de datos, y para ello dispone de un motor de mezcla llamado Power Query.

El lenguaje «M» se utiliza en toda conexión inicial. Contiene más de setecientas (700) funciones. Es decir, puedes dedicarte exclusivamente a las etapas de ETL, y hacer una carrera profesional como especialista en extracción, transformación y carga de datos.

Lo normal es que los datos no contemplen la estructura adecuada para ser procesados (exceptuando aquellos provenientes de bases de datos). Y, precisamente con la amplitud de funciones, y acciones que solamente requieren de presionar un botón en el menú, se pueden conseguir las transformaciones necesarias. Power Query también se encuentra en Excel; pero a diferencia de la hoja de cálculo, siendo un aspecto, digamos «opcional», para un flujo de análisis en Power BI Desktop es de carácter obligatorio.

Y aquí, es importante recalcar lo siguiente: cuando se trabaja en Power BI, se deben cumplir con una serie de prácticas y postulados que son mucho más antiguos que el programa. Esto, hace necesario cambiar los enfoques aceptados en el procesamiento de datos en las hojas de cálculo; evitando crear los llamados «modelos espagueti» donde la mente no ha caído en cuenta, que es otro programa, son otras reglas y, de no cumplirse tendrás problemas no solo en el presente, sino en el futuro inmediato.

En Power BI Desktop todo esta concatenado, y la primera parada es el motor de mezcla.

Un lenguaje complicado; pero muy potente

DAX es el culpable de la mayor cantidad de canas y trasnochos.

Sin embargo, un par de cálculos complejos pueden convertirse en el ancla para justificar resultados que jamás; pero ni en el mejor de los escenarios hubiesen sido posible lograrlos bajo el enfoque clásico de procesamiento de datos. El lenguaje, tiene una pared elevada de adopción, tal y como he comentado anteriormente aquí y acá.

Asimismo, cuando crees que lo estas dominando, algo sucederá para hacerte bajar el ego; y decirte: apenas lo estas comenzando a comprender…

No obstante, debido a su nivel de abstracción y capacidad de generar reglas de negocio robustas; justifica su profundización. Y, a medida que se estudia, mejorando nuestras sintaxis, y comprendiendo lo que sucede paso a paso; lo complejo tiende a desvanecerse –al menos temporalmente…– dándole cabida a la adopción de alternativas encontradas a traves de libros, videos, foros y blogs especializados.

Pero, no hay que engañarse: es necesario llenarse de valentía para aprender sobre el lenguaje; porque las consecuencias de no lograr la suficiente complejidad pueden hacer tambalear la adoptación del programa.

Visualizar para creer

El grado de tecnicismo que puede lograrse al momento de diseñar un reporte o dashboard sigue siendo desconocido para la mayoría de los usuarios. En cierta manera, la visualización se sobre simplifica y, hasta puede confundirse el grado de complejidad necesario para llegar a la mente, activando el proceso de toma de decisiones.

Crear gráficos esta predefinido: arrastrar y soltar elementos al canvas, y luego llenar los campos requeridos para definir sus valores; de ser necesario, se modifican las configuraciones predeterminadas en cada una de las opciones.

La visualización de datos en Power BI converge entre objetos visuales nativos, y un mercado de aquellos creados por terceros, por ejemplo: Potencia de personalización visual: Deneb y Vega-Lite.

Al descentralizar la capa de visualización con productos de terceros, el usuario tiene la oportunidad de utilizar diversidad de gráficos desde el AppSource. Sin embargo, entre aquellos gratuitos y los que deberán ser pagados puede existir una brecha importante en términos de fiabilidad y capacidades técnicas.

El mayor ejemplo ocurre en el segmento de las Finanzas con Zebra BI. Si queremos alcanzar un comportamiento visual o como mínimo replicar cálculos que en DAX pueden ser verdaderamente complejos para la mayoría de los usuarios; con pagar licenciamiento se consigue el mismo comportamiento, pero de manera automática.

Esto nos lleva a preguntarnos si los usuarios tendrán el interés de aprender la complejidad de un lenguaje para alcanzar los resultados visuales esperados; o mejor se invierte en licenciamiento exclusivo para la capa de visualización; evitando fracasos por expectativas demasiado elevadas.

La visualización de datos en Power BI es lo suficientemente amplia para complacer a una gran cantidad de usuarios; pero para los más especializados, verán fallas o limitantes, llamémosle «básicas» en comparación a sus competidores. La falta de consistencia y criterios técnicos en el apartado visual pueden ser invisibles para la mayoría; pero no para quienes hacen vida laboral estrictamente diseñando reportes y cuadros de mando.

Otros lenguajes

Además del lenguaje «M» y DAX, en Power BI Desktop se pueden realizar consultas en Lenguaje Natural: escribir palabras para construir gráficos de inmediato. En la visión del cuadrante mágico de Gartner (2017-2018) estimaban que una gran cantidad de las consultas en plataformas de Inteligencia Empresarial serian bajo esta modalidad; pero la realidad es muy diferente.

Por un lado, se requiere de optimizaciones importantes en los modelos para garantizar que las preguntas sean respondidas correctamente, y quizás, la más importante: ¿El usuario querrá escribir para responder sus dudas?

Un cambio de paradigma. Sin embargo, con la próxima incorporación de GPT-3 en DAX se espera una mayor precisión al momento de sintaxis sugeridas –a diferencia de las llamas medidas rápidas que en realidad son bastante lentas-.

Tambien es posible utilizar SQL a nivel de consultas o creación de tablas para ser indexadas en Power Query. Asimismo, Python y «R» en la capa de transformación de datos o de visualización.

En sí, la variedad de opciones para afrontar un desarrollo basado en este programa da la suficiente flexibilidad para abordar multiples escenarios. Pero; la principal limitante nos apunta al desconocimiento sobre las potencialidades, y las integraciones que existen a traves de toda la plataforma.

Es parte de una plataforma

Power BI es un programa que forma parte de una plataforma que, si bien no es necesario utilizar toda la amplitud de servicios o características asociadas en un despliegue; puede que, al verse como un todo, nos dé una idea de su magnitud.

En ese sentido, Melissa Coates comparte anualmente un diagrama con una selección de las principales características, puntos de integración y servicios asociados.

Puedes descargar la versión en PDF aquí.

A lo que vengo con esto es recordarnos que, lo que llevamos a cabo en el programa es solamente parte de un engranaje.

Programas externos

Los programas y servicios de terceros han asumido el rol de desarrollo compartido con Microsoft. Sin ellos, la creación de modelos analíticos de corte empresarial seria extremadamente engorroso; de verdad, horrible.

Solamente el equipo de SQLBI ofrece: Bravo para Power BI, DAX Studio, Tabular Editor, VertiPaq Analyzer, y páginas con servicios asociados como DAX.do y DAX Formatter.

Y eso, es solo una muestra de un grupo; porque existe variedad de aplicaciones creadas por parte de la comunidad.

Sin embargo, a medida que se van descentralizando características consideradas «avanzadas» por fuera de Power BI Desktop, llega un punto donde la experiencia de desarrollo para profesionales a nivel de capa semántica deja de hacerse en el programa. Dejando solamente la capa de visualización (porque lo demás se desarrolla en estos programas de terceros) desde nuevas medidas, relaciones, configuraciones de seguridad, formatos, etcetera.

Podría decirse que un usuario inicial utiliza las características nativas; mientras que los más curtidos las desechan por el impacto en el tiempo y la productividad.

Metodología de despliegue

El error más común es pensar que trabajar con Power BI es similar al enfoque llevado a cabo sobre análisis en hojas de cálculo.

Y, si bien en la forma o producto final pueden parecerse; en el ámbito empresarial se deben cumplir prácticas que han ido evolucionando a partir de cómo creamos, procesamos y comunicamos datos.

Dejar que los usuarios creen de manera indiscriminada modelos analíticos lleva a la anarquía. La gobernancia no puede dejarse de lado ante la versatilidad del Autoservicio «Self-Service BI».

Lo normal o esperado es que exista una cantidad reducida de desarrolladores/creadores de modelos. Luego, una mayor proporción de creadores de reportes y cuadros de mando y, por último, siendo la mayor cantidad los usuarios de consumo –quienes solamente tienen que ver e interactuar en la capa de visualización-.

Impacto en la cultura analítica

Cierro el artículo con lo más importante: la cultura analítica.

Intangible, insipiente e inentendible para muchos, la cultura permea en la mente de las personas, moldeando su rol con el interactuar de los datos.

La cultura analítica puede tumbar el proyecto más robusto porque la mente sencillamente es perezosa; cambiar algo tan delicado como la relación con los datos podría considerarse una amenaza.

Hay que comprender a las personas, sus intereses, y disponer de los argumentos técnicos y humanos adecuados para tener éxito en lo que respecta desplegar Power BI como plataforma de Inteligencia Empresarial.