Análisis predictivo en Power BI: lo que ya trae y lo que falta para decidir stock.

Qué hace en análisis predictivo en power bi.

¿Qué es el análisis predictivo en Power BI?

El análisis predictivo es usar datos pasados para estimar qué va a ocurrir, con una medida de cuánto puede fallar la estimación. En Power BI aparece de tres formas: la previsión y la detección de anomalías del panel Análisis, el AutoML de Microsoft Fabric para quien programa notebooks, y un modelo externo cuyo resultado se importa como una tabla más del modelo semántico.

Aquí hablamos de análisis predictivo aplicado a ventas, stock y reposición: cuánto se va a vender de cada producto en cada tienda, almacén o cliente, y con qué probabilidad te quedas sin él antes de que llegue el siguiente pedido. No hablamos de bajas de clientes, de marketing ni de recursos humanos, que son otros problemas con otros datos.

¿Qué trae Power BI de serie para predecir?

En el panel Análisis hay dos funciones predictivas, y las dos están limitadas al gráfico de líneas. La primera es Previsión: según la documentación de Microsoft, hace falta tener datos de tiempo, y puedes indicar la longitud de la previsión y el intervalo de confianza. La segunda es Anomalías, que marca los picos y las caídas inesperadas de una serie temporal.

La detección de anomalías dibuja el rango esperado de la serie y marca como anomalía lo que sale de él. Tiene un control de sensibilidad: si la subes, hasta una desviación pequeña se marca, y si la bajas, solo las grandes. Microsoft remite al algoritmo SR-CNN del servicio Anomaly Detector. Si seleccionas una anomalía, Power BI analiza los campos del modelo y te da una explicación en lenguaje natural con los factores asociados, ordenados por fuerza.

Lo mejor de este panel es que no hay que programar nada y se prueba en cinco minutos. Para un primer vistazo a una familia de productos, o para entender por qué un mes se disparó, es una herramienta honesta. La pregunta es qué pasa cuando de lo que se mira hay que pasar a lo que se decide.

¿Qué límites tiene, según la documentación?

Los límites de la detección de anomalías están escritos en la propia documentación: solo funciona en gráficos de líneas con serie temporal en el eje, no admite leyenda, ni varios valores, ni valores secundarios, y necesita al menos cuatro puntos. Las líneas de previsión, mínimo, máximo, media, mediana y percentil no funcionan junto a ella. En el aviso para la Previsión, Microsoft recuerda que solo existe para gráficos de líneas.

De esos límites sale uno práctico. Un gráfico de líneas sin leyenda es una serie. Un catálogo de 3.000 productos en 40 sitios son 120.000 series. Nadie va a configurar 120.000 gráficos, y aunque se hiciera, el resultado de cada uno vive dentro del gráfico: no se puede usar en una medida para ordenar los productos por riesgo ni para calcular cuánto pedir.

Los dos usos son de exploración, y como tales funcionan bien. El problema es pedirles que decidan una reposición.

¿Y el AutoML de Fabric?

Microsoft Fabric incluye AutoML mediante la biblioteca FLAML, que se usa desde notebooks de Python con el mismo estilo que un estimador de Scikit-learn. Según la documentación, admite clasificación, regresión y previsión de series temporales, y para series temporales hay modelos como AutoARIMA, Prophet, Holt-Winters, LightGBM y XGBoost. Cada intento queda registrado con MLflow, de modo que se puede ver cómo se eligió el modelo final.

Para un equipo de datos que ya trabaja en Fabric es una buena forma de probar modelos con poco código. Lo que no hace es decidir por ti qué datos entran, cómo se tratan las semanas sin stock, cómo se valida con el tiempo por delante ni cómo se convierte la previsión en una cantidad con un riesgo. Eso es trabajo de modelado que hay que hacer igual, con AutoML o sin él.

Un ejemplo con números: la semana en la que se acabó el ventilador.

Menaje Almendral, una empresa de ejemplo que reparte menaje a ocho tiendas, vende de media 5 ventiladores de pie por semana y tienda. Una semana de calor, la tienda de Málaga tenía 30 unidades y las vendió el martes. El miércoles y el jueves vendió cero, no porque nadie quisiera uno, sino porque no había. La semana cerró en 30 unidades vendidas, cuando con stock habrían sido unas 55.

En el gráfico de líneas, la detección de anomalías marca el pico de la semana y puede marcar el hundimiento de la siguiente. Hasta ahí, correcto. Pero la previsión del gráfico aprende de esos 30 como si fueran la demanda, y la semana siguiente prevé de menos justo donde más se vendió. El dato dice «Málaga vendió 30», y lo que pasó es que Málaga tenía 30.

Un modelo para reposición trata aquella semana como demanda no observada: sabe que el stock llegó a cero el martes, así que no la usa como si fuera una venta normal. Por eso el modelo lee también el stock diario, además de las ventas. Es la diferencia más grande entre predecir una serie y predecir la demanda que de verdad había.

¿Cómo se monta el modelo fuera y se enseña en Power BI?

El orden es siempre el mismo. El sistema lee ventas y stock del programa que ya usas (Business Central, Odoo, Sage o una hoja de Excel) con un usuario que solo puede leer, construye el modelo con todos los sitios a la vez, lo valida con fechas pasadas y calcula cada semana, para cada producto y sitio, la previsión, un límite inferior, un límite superior y la probabilidad de rotura.

Esas columnas se publican en un origen que tu Power BI ya actualiza: una base de datos, un almacén de datos o un archivo. Se relacionan con las tablas de producto, sitio y calendario que ya existen, y entran en el modelo semántico como cualquier otra tabla, con sus filtros y sus permisos. Quien mantiene hoy tu informe lo sigue manteniendo. Si lo mantiene un consultor, trabajamos con él.

La banda se dibuja con el propio panel Análisis. Las barras de error de Power BI se pueden definir por campo, con un límite superior y uno inferior del modelo, y en los gráficos de líneas hay una banda de error en relleno, en línea o en ambos. Ahí encajan los límites que calcula el sistema. El abanico que ves sale del error real de cada producto en el pasado, no de un cono dibujado por defecto.

¿Cómo se enseña lo que el modelo acierta?

Con la previsión en el modelo, una medida compara cada semana lo previsto con lo vendido y calcula el error por producto, familia y sitio. Para que una referencia de 2 unidades no pese como una de 2.000, el error se mide ponderado por volumen, como explica la guía del WMAPE. Se puede ver dónde acierta el modelo y dónde falla, con los mismos filtros que ya usas.

Aquí sí tiene sentido la detección de anomalías de Power BI, pero aplicada a otra serie: la del error semanal. Un error que de pronto sale del rango esperado avisa de que algo cambió en un producto o en una tienda, por ejemplo una promoción que el modelo no conocía. Es un uso mejor que pedirle que prediga, y lo hace sin que haya que programar nada.

La otra mitad es la calibración. Cuando el sistema dice un 5 % de riesgo de rotura, tiene que ocurrir más o menos un 5 % de las veces. Una página del informe cuenta cuántas veces ocurrió de cada tramo de riesgo en las últimas semanas, y es la que más conviene enseñar a Dirección antes de fiarse.

¿Qué datos hacen falta de tu parte?

Lo mínimo son las ventas por producto, sitio y fecha, el stock diario o semanal (para saber qué semanas se vendió cero por falta de producto) y las fechas de pedido y recepción de cada proveedor. Con dos años de historia se aprende la temporada. Con menos se puede trabajar, y se dice con claridad qué parte es fiable y cuál no.

Ayudan, sin ser imprescindibles, las promociones pasadas, el calendario de campañas y las roturas ya registradas. De Power BI hace falta saber de dónde lee y quién mantiene el informe, y un origen donde dejar las tablas del sistema. No necesitamos que migres nada ni que cambies de programa.

¿Qué no hace, y cómo se empieza?

No sustituye a tu Power BI ni lo rehace: añade páginas y tablas. No entrena modelos de bajas de clientes, de marketing ni de recursos humanos. No promete un porcentaje de acierto antes de ver tus datos, porque depende de cuánto se parezca tu venta de un año al siguiente. Y no pide nada a tu ERP que no sea leer, ni escribe pedidos sin que una persona los apruebe.

Se empieza con una simulación sobre tus datos: se repiten fechas pasadas con lo que se sabía ese día, se compara lo que habría propuesto el sistema con lo que se hizo y se enseña en tu propio Power BI. Si compensa, vienen uno o dos meses en modo sombra y el arranque en 3 a 6 semanas. Para verlo, reserva una demo de 30 minutos por videollamada o pide el análisis gratuito.

¿Te suena alguno de estos casos?

• Si Dirección pide «algo de IA en el Power BI» y el informe tiene cuarenta páginas de pasado. El paso útil es una página de futuro por producto y sitio, con la banda y lo que ocurrió después.
• Si alguien ya ha activado la previsión de un gráfico y Compras la mira pero sigue pidiendo por intuición. El gráfico enseña la familia, no dice cuánto pedir de cada referencia en cada tienda.
• Si el equipo de datos usa Fabric y quiere un modelo de verdad sin montarlo todo. El modelo se entrena fuera y su salida entra en el modelo semántico que ya mantenéis.
• Si las ventas bajan justo cuando se acaba el producto y la previsión aprende que «ese producto vende poco» en esa tienda. Ese sesgo se corrige tratando las semanas sin stock aparte.
• Si las anomalías del gráfico salen cada semana y nadie sabe cuáles importan. Se filtran por impacto en stock: la que deja una tienda sin producto antes del próximo pedido va arriba.

Power BI para ver y explorar, un modelo propio para decidir, y los dos hablan el mismo idioma.

El análisis predictivo del panel Análisis es de exploración: rápido, visual y sin código. Decidir una reposición pide otra cosa: un modelo que conozca el stock y los plazos, que sepa cuánto se equivoca y que se haya probado con tu histórico. Ese modelo no sustituye a tu Power BI: le entrega una tabla y se queda en el informe que ya usáis.

• Previsión por producto y sitio, con banda propia y riesgo de rotura, no una línea por gráfico.
• Entra en el modelo semántico como tabla: sirve para medidas, filtros, permisos y listas ordenadas.
• Comprobada con fechas pasadas de tu negocio antes de decidir nada en vivo.
• Una persona aprueba cada propuesta; el pedido sale de tu ERP.