Control de stock en Power BI con IA: del informe a lo que hay que pedir.

Qué hace en con power bi.

Qué hace un panel de inventario en Power BI, y qué no.

Un buen panel de inventario en Power BI enseña, con un par de clics, lo que antes costaba una mañana de Excel: el valor del stock por almacén y familia, la rotación, la cobertura en días, los artículos sin movimiento en seis meses, las roturas del mes, las ventas frente al año pasado. Lee del ERP, de una base de datos o de unos Excel en SharePoint, se actualiza solo cada noche y cada uno ve lo suyo con sus permisos. Para Dirección es la foto del lunes; para Compras, la lista de lo que anda justo.

Lo que no hace es decidir. Power BI es una herramienta para mirar datos, y lo hace muy bien, pero no calcula cuánto hay que pedir de cada producto ni escribe en ningún sitio. La «previsión» que trae en los gráficos de líneas proyecta una serie hacia adelante con una banda de confianza: útil para ver la tendencia de una familia, inútil para decidir un pedido, porque no sabe el stock de hoy, lo que está en camino, el plazo del proveedor ni lo que cuesta mandar un envío. Y es una serie cada vez: con 2.000 productos y 15 almacenes son 30.000 series.

De «cobertura de 12 días» a «pide 40 el martes».

La cobertura en días, que casi todos los paneles enseñan, es el stock dividido entre la venta media. Dice «te quedan 12 días» y es un buen aviso, pero no basta para decidir. Para decidir hace falta saber cuánto se va a vender en esos días y en los siguientes como un abanico (lo más probable y lo que puede pasar), cuánto tarda el proveedor de ese producto, qué riesgo hay de quedarse a cero antes de que llegue, y si pedir ahora compensa frente a esperar al siguiente pedido a ese proveedor.

Eso lo calcula el motor de previsión, producto a producto y almacén a almacén, con las mismas ventas y el mismo stock que ya lee vuestro Power BI. La temporada se aprende con todos los puntos a la vez, las promociones se marcan aparte y el plazo de cada proveedor se saca de las fechas reales de pedido y recepción. El resultado no es un gráfico: es una lista de qué pedir esta semana, con la cantidad y el porqué en una frase, y un riesgo de rotura por producto que significa lo que dice.

Cómo entra en vuestro Power BI: tablas, no otro panel.

El motor no sustituye a Power BI ni añade otro panel que mirar. Calcula fuera, en vuestra infraestructura o en la nuestra según prefiráis, y escribe el resultado en tablas: previsión por producto, almacén y semana; riesgo de rotura; propuesta de pedido con su porqué; previsto frente a real. Esas tablas van a vuestra base de datos, a un almacén de datos en Azure, a Fabric si lo tenéis, o a archivos en la misma carpeta de SharePoint que ya lee vuestro informe. Lo único que importa es que sea un origen que la actualización programada de Power BI ya recoge.

En el modelo, las tablas nuevas se relacionan con las de producto y almacén que ya existen, así que los filtros, las jerarquías y los permisos de siempre funcionan sobre ellas sin tocar nada. Las páginas nuevas se añaden al informe que ya tenéis, con vuestro tema y vuestra forma de hacer las cosas. Si vuestro informe lo hizo un consultor y nadie quiere rehacerlo, no hay que rehacerlo; si el consultor sigue, trabajamos con él.

Las fuentes son las mismas. Si Power BI ya lee de Sage, de Odoo o de una base de datos, el motor usa esa misma conexión o esa misma exportación. No se duplica nada ni se pide una segunda vía de acceso a la empresa.

Las tres páginas que se añaden al informe.

La primera es «qué pedir esta semana»: la lista de productos y almacenes con la cantidad propuesta, ordenada por lo que se pierde si no se pide, con filtro por proveedor, almacén y familia, y el porqué de cada línea. Es la página de Compras, y está pensada para que de ahí salga el pedido, no para mirarla.

La segunda es «riesgo de rotura»: para cada producto y almacén, la probabilidad de quedarse a cero antes de que llegue el siguiente pedido, con el nivel que hayáis fijado (un 5 % en temporada baja, un 2 % en campaña). Se ve de un vistazo qué está en rojo y por qué, y también lo contrario: qué productos tienen tanto stock que no hay riesgo en meses, que es el dinero parado.

La tercera es «previsto frente a real»: cada mes y cada campaña, lo que el modelo previó y lo que pasó, por país, familia o almacén. Es la página de Dirección, y es la que hace que el modelo sea discutible. Un modelo que no se puede comprobar con sus propios filtros es una opinión.

Los indicadores de inventario, con una sola definición.

Casi todos los paneles que han ido creciendo tienen el mismo problema: tres rotaciones distintas según quién hizo cada página, una cobertura que unos calculan con la venta de 30 días y otros con la de 90, y unas roturas que para Compras son «producto a cero» y para Ventas son «pedido que no se pudo servir». Antes de añadir previsión, se fijan y se escriben las definiciones, y se dejan en el modelo como medidas únicas.

Las que importan para el stock son pocas: rotación (cuántas veces al año se vende el stock medio), cobertura (días que dura el stock al ritmo previsto, no al medio), nivel de servicio (demanda atendida sobre demanda total, que es lo que de verdad mide si el cliente encontró lo suyo), roturas (días a cero por producto y ventas perdidas en euros), stock parado (euros en producto sin venta en X meses) y acierto de la previsión (error entre lo previsto y lo real). La guía de rotación de inventario y la de nivel de servicio explican cada una con ejemplos.

Cómo se comprueba antes de publicar una sola tabla.

Antes de que nada aparezca en vuestro Power BI, el motor pasa un examen con vuestros propios meses pasados: vuelve a decidir cada semana solo con lo que se sabía esa semana, partiendo del stock que había de verdad, y se compara con lo que hicisteis. Las medidas se fijan antes de ver el resultado: demanda atendida, ventas perdidas en euros, pedidos, unidades y dinero parado.

Las cifras de esa simulación (demanda atendida, envíos y unidades, lo que hizo el programa frente a lo que hiciste tú), con sus filtros por zona y por punto de venta, son exactamente lo que se publica en la página de previsto frente a real. También se publica dónde falla, para vigilarlo.

Después, uno o dos meses en modo sombra: la página de qué pedir se publica cada semana, vosotros pedís como siempre y al final se mide qué habría pasado. Solo entonces la propuesta pasa a ser la que se usa.

Cuándo con tu panel te basta.

Si tenéis un almacén, unos cientos de productos y proveedores que sirven en pocos días, un panel con cobertura en días y una regla de punto de pedido en el ERP os sobran, y la calculadora de rotación de inventario os ayuda a poner la regla bien. Añadir previsión a eso es complicarlo. Os lo diremos en el diagnóstico.

Compensa cuando el panel ya enseña el problema y no la salida: muchos puntos de venta o almacenes, temporada marcada, proveedores lentos, envíos que cuestan, y una reunión del lunes que acaba en «¿y entonces qué pedimos?». Si es vuestro caso, con una exportación de ventas y stock os devolvemos un análisis gratuito: qué se rompió, cuántos días, cuánto dinero hay parado y qué cambiaríamos primero.

¿Te suena alguno de estos casos?

• Si tenéis un panel de inventario que Dirección mira cada lunes y la reunión acaba en «¿y entonces qué pedimos?». El panel ya tiene las fuentes y los permisos. Se le añade la página de qué pedir esta semana, con el porqué, y la reunión cambia de pregunta.
• Si un consultor os hizo el Power BI y nadie en la empresa lo quiere rehacer No hace falta. Las nuevas tablas entran en el modelo como una fuente más y las páginas nuevas respetan lo que hay. Si el consultor sigue, trabajamos con él.
• Si sois distribuidor con puntos de venta en varios países y un almacén de datos Las ventas por punto ya están en vuestra base de datos. El motor lee de ahí, aprende el calendario de cada país y publica la propuesta de envío por punto de venta en el mismo panel donde ya miráis las ventas.
• Si lleváis el stock en Sage, Odoo u otro ERP y Power BI encima Power BI ya sabe leer de vuestro ERP, así que el camino está hecho. El motor usa la misma conexión o la misma exportación, y el pedido vuelve al ERP, no al panel.
• Si cada departamento tiene su propia rotación Compras calcula una, Finanzas otra y el panel una tercera. Antes de prever nada se fijan las definiciones, se escriben y se dejan en el modelo. Solo eso ya ahorra discusiones.

No es otro panel. Es el «cuánto pedir» dentro del que ya tienes.

Hay quien propone cambiar Power BI por su propia herramienta de previsión con sus propios gráficos. Aquí es al revés: vuestro Power BI ya tiene las fuentes, los permisos y la costumbre de mirarlo, y eso vale mucho. El motor de previsión calcula fuera, con las mismas fuentes, y publica la decisión como tablas en vuestro modelo. Se comprueba con vuestro histórico antes de publicar nada, y el código y las tablas son vuestros.

• Las mismas fuentes que ya lee tu Power BI. Sin duplicar conexiones ni datos.
• La previsión y la propuesta entran como tablas del modelo: tus páginas, tus filtros, tus permisos.
• Indicadores de inventario con una sola definición, escrita y compartida.
• La propuesta también vuelve al ERP o a una hoja por proveedor: el pedido no se hace desde un gráfico.