Previsão de demanda para o planejamento logístico

Errar a demanda custa dos dois lados, e o Excel não avisa#

Na logística, todo erro de previsão tem preço. Prever demanda a mais gera estoque parado, capital imobilizado e risco de perda. Prever a menos gera ruptura, venda perdida e frete expresso para tapar buraco. A previsão de demanda logística é o eixo que decide quanto comprar, quando comprar e quanto manter em cada centro de distribuição. Feita no olho, ou numa planilha que ninguém mais entende, ela vira aposta.

Este artigo é para quem planeja abastecimento, S&OP ou reposição e quer sair do achismo sem cair no outro extremo, o de acreditar que um modelo de machine learning resolve tudo sozinho. Vou tratar dos conceitos que sustentam o planejamento (sazonalidade, estoque de segurança, ponto de pedido e cobertura), do que o recurso nativo de forecast do Power BI faz e não faz, e de quando vale subir para Azure Machine Learning ou Microsoft Fabric. Com honestidade sobre os limites de cada abordagem.

Sazonalidade não é opcional: é a espinha dorsal do modelo#

Demanda logística quase nunca é estável. Ela tem padrão semanal (segunda difere de sábado), padrão mensal (fechamento, quinzena) e padrão anual (Black Friday, Natal, safra, volta às aulas). Ignorar esses ciclos é o erro mais comum e mais caro.

Antes de qualquer previsão, você precisa separar três componentes do histórico:

• Tendência: a demanda está crescendo, caindo ou estável no médio prazo.
• Sazonalidade: os ciclos que se repetem em períodos fixos.
• Ruído: a variação aleatória que nenhum modelo captura, e que é justamente o que o estoque de segurança existe para absorver.

Uma armadilha frequente é confundir sazonalidade com evento pontual. Uma promoção única, uma greve de transporte ou uma ruptura de fornecedor distorcem o histórico. Se você não marcar esses outliers, o modelo aprende que aquele pico se repete todo ano. Limpar o histórico, tratar datas atípicas e marcar feriados móveis não é preciosismo, é o que separa uma previsão utilizável de um gerador de números bonitos.

Para modelar isso bem, o dado precisa estar organizado. Uma tabela calendário completa, com marcação de feriados, campanhas e eventos comerciais, costuma valer mais do que o algoritmo escolhido. É trabalho de engenharia de dados antes de ser trabalho de BI.

Os quatro números que o planejador realmente usa#

Previsão de demanda não é o produto final. O que o planejador executa são políticas de estoque derivadas da previsão. Quatro conceitos concentram quase toda a decisão operacional.

Conceito	O que responde	Fórmula prática
Estoque de segurança	Quanto manter para absorver variação	Z x desvio-padrão da demanda x raiz(lead time)
Ponto de pedido (ROP)	Quando disparar o pedido	demanda média no lead time + estoque de segurança
Cobertura de estoque	Por quantos dias o estoque atual dura	estoque atual / demanda média diária
Estoque máximo	Teto para não superestocar	ponto de pedido + lote de compra

O estoque de segurança depende do nível de serviço desejado. O fator Z traduz esse nível: quanto maior a meta de disponibilidade, maior o Z e maior o estoque parado. Aqui está uma das decisões mais políticas da logística, porque quase ninguém quer assumir que 99% de nível de serviço custa muito mais caro que 95%. Um bom painel deve deixar esse trade-off explícito, item a item.

O ponto de pedido amarra previsão e lead time do fornecedor. Se o lead time é volátil, e no Brasil ele costuma ser, o estoque de segurança precisa cobrir a variação do prazo de entrega, não só a da demanda. Modelos que assumem lead time fixo falham silenciosamente.

A cobertura é o indicador que o gestor olha primeiro, porque é intuitivo. Mas cobertura média engana: 30 dias de cobertura podem esconder um SKU com 200 dias e outro em ruptura. Cobertura precisa ser analisada por item e por curva ABC, nunca só no agregado.

O forecast nativo do Power BI resolve o começo, não o fim#

O Power BI tem um recurso de previsão embutido no visual de linha. Você habilita a análise de previsão, define o número de períodos à frente, o intervalo de confiança e a sazonalidade, e ele projeta a série. Por baixo, ele usa suavização exponencial (famílias ETS), que capta nível, tendência e sazonalidade de uma série univariada.

É útil, e subestimado. Para um gestor que hoje projeta demanda no chute, ver a série com intervalo de confiança já é um salto. Serve bem para visão agregada, para poucas séries e para comunicação executiva. Combinado com uma boa modelagem DAX, você monta um painel de S&OP decente em dias.

Mas é honesto reconhecer os limites, porque eles são reais:

• É univariado. Só olha o histórico da própria série. Não incorpora preço, promoção, clima, câmbio ou qualquer variável externa (regressor).
• Não escala para milhares de SKUs de forma governada. O forecast do visual é para exploração, não para gerar uma tabela de previsão por item que alimenta o cálculo de reposição.
• Não versiona nem registra acurácia. Você não tem histórico de erro do modelo (MAPE, WMAPE) para saber se ele está piorando.
• Séries curtas, intermitentes ou com muitos zeros (demanda esporádica) quebram a suavização exponencial. E demanda intermitente é a regra em peças de reposição e cauda longa.

Ou seja: o forecast nativo é ótimo como camada de visualização e como MVP. Ele não é o motor de planejamento de uma operação com milhares de itens. Quem promete isso está vendendo o visual como se fosse a plataforma.

Quando subir para Azure Machine Learning ou Fabric#

A pergunta certa não é "qual algoritmo", é "onde o cálculo pesado deve rodar". Previsão por SKU, com variáveis externas e reprocessamento frequente, é carga de dados e de compute, não trabalho de um visual de dashboard. Existem dois caminhos principais no ecossistema Microsoft, e eles não competem: se complementam.

Abordagem	Melhor para	Limitação principal
Forecast nativo do Power BI	Visão agregada, MVP, comunicação	Univariado, não escala por SKU
Azure Machine Learning	Modelos customizados, muitas features, MLOps	Exige time de dados, mais custo de setup
Microsoft Fabric (notebooks + Direct Lake)	Pipeline unificado dado a painel	Consumo em Capacity Units a dimensionar

O Azure Machine Learning é o ambiente para treinar modelos multivariados de verdade: você pode usar regressores externos, testar algoritmos como gradient boosting ou modelos de série temporal mais robustos, e ainda usar AutoML para forecasting com backtesting embutido. Ganha versionamento de modelo, registro de acurácia e reprocessamento agendado. O custo é organizacional: exige um time que sustente o modelo, não só quem o cria. Isso é território de analytics avançado.

O Microsoft Fabric, anunciado pela Microsoft em 2023, unifica engenharia de dados, ciência de dados e BI sobre o OneLake. Na prática, você processa o histórico e treina o modelo em notebooks (Spark ou Python), grava a tabela de previsão no OneLake e o Power BI lê pelo modo Direct Lake, sem importar nem duplicar o dado. É elegante para logística porque o ciclo dado bruto, previsão, política de estoque e painel fica num só ambiente governado. O ponto de atenção é comercial e técnico: o Fabric mede consumo em Capacity Units, com SKUs de F2 a F2048, e capacidade mal dimensionada gera throttling ou conta alta. Vale ler nossa análise sobre o que é o Microsoft Fabric e quando vale a pena antes de decidir.

Uma nota técnica que importa no dimensionamento: o motor VertiPaq, que sustenta os modelos do Power BI e do Fabric, comprime colunas por cardinalidade. Tabelas de previsão diária por SKU explodem cardinalidade (data x item), o que pesa na memória. Modelar granularidade com critério, agregar onde a decisão não exige o detalhe diário, faz diferença real de performance e de custo.

Licenciamento: o detalhe que trava projeto no final#

Vale alinhar cedo, porque é onde muitos projetos travam na hora de publicar. Compartilhar conteúdo no Power BI exige licença: Power BI Pro e PPU (Premium Per User) são licenças por usuário, enquanto capacidade dedicada vem por SKUs de capacidade (as antigas P1 a P5 do Premium e as atuais F do Fabric). Se a previsão vai virar painel consumido por dezenas de planejadores e compradores, o custo de licença entra na conta desde o discovery, não depois. Um bom discovery e assessment resolve isso antes de virar surpresa.

Preços variam por contrato, moeda e canal, e devem ser confirmados na fonte oficial da Microsoft. Como faixa aproximada: licenças por usuário ficam na casa de poucas dezenas de reais por usuário ao mês, enquanto capacidade dedicada envolve valores bem maiores e escalonados por SKU. Trate qualquer número como estimativa a validar.

Nenhum modelo substitui o planejador: ele o municia#

Aqui entra a parte que consultoria honesta precisa dizer. Previsão de demanda é uma estimativa com incerteza embutida, e vai errar. O objetivo não é acertar o número, é errar menos e de forma medida, com uma política de estoque que absorve o erro residual.

Três verdades que costumam desapontar quem espera mágica:

• Acurácia tem teto. Demanda com muita aleatoriedade tem um limite de previsibilidade que nenhum algoritmo vence. Investir em modelo mais complexo além desse ponto é queimar dinheiro.
• Dado ruim derruba qualquer modelo. Cadastro de SKU inconsistente, histórico com furos, devolução misturada com venda. Sem governança de dados, o melhor modelo entrega lixo bem formatado.
• A exceção continua humana. Lançamento sem histórico, mudança de fornecedor, evento de mercado. O modelo dá a base; o planejador ajusta com contexto que o dado ainda não tem.

E há a dimensão legal, que a logística às vezes esquece. Dados de demanda cruzam pedidos, clientes e às vezes comportamento de consumo. Onde há dado pessoal, a LGPD (Lei nº 13.709/2018) se aplica, e o painel de previsão precisa respeitar minimização e controle de acesso como qualquer outro ativo de dado. Tratamos disso em detalhe no artigo sobre governança, LGPD e Power BI.

O bom projeto de previsão mede o próprio erro em produção. Acompanhar WMAPE por curva ABC, comparar previsão contra realizado e ter alerta quando o modelo degrada é o que mantém a confiança viva. Isso é trabalho contínuo, de sustentação de BI, não entrega de uma vez só.

Um caminho de implantação que funciona na prática#

Para logística, o que dá certo raramente é começar pelo modelo mais sofisticado. Um roteiro realista:

1. Organizar o histórico: calendário, curva ABC, tratamento de outliers e datas atípicas. Sem isso, nada adiante.
2. MVP no forecast nativo do Power BI: visão agregada, intervalo de confiança, S&OP básico. Prova valor rápido e alinha linguagem.
3. Políticas de estoque em DAX: estoque de segurança, ponto de pedido e cobertura por item, com o trade-off de nível de serviço visível.
4. Escalar por SKU em Azure ML ou Fabric só quando o volume e as variáveis externas justificarem, com backtesting e registro de acurácia.
5. Sustentar: monitorar erro, revisar sazonalidade e ajustar parâmetros por ciclo.

Esse caminho evita os dois fracassos clássicos: o painel bonito que ninguém usa, e o projeto de ciência de dados que morre antes de entregar o primeiro número útil.

Perguntas frequentes#

O forecast do Power BI serve para prever demanda por SKU? Serve para poucas séries e visão agregada, mas não para milhares de itens de forma governada. Ele é univariado e não gera uma tabela de previsão por item versionada. Para reposição item a item, o cálculo pesado deve rodar em Azure Machine Learning ou em notebooks do Fabric, com o Power BI atuando como camada de visualização.

Qual a diferença prática entre usar Azure ML e Fabric para isso? Azure Machine Learning é o ambiente maduro de MLOps: modelos customizados, muitas variáveis, versionamento e agendamento. O Fabric unifica todo o ciclo, do dado bruto ao painel, sobre o OneLake, com o Power BI lendo em Direct Lake sem duplicar dado. Se sua operação já vive no ecossistema Microsoft e quer um pipeline único, o Fabric tende a simplificar. Se você precisa de MLOps robusto e flexibilidade máxima de modelo, o Azure ML entrega mais.

Como o estoque de segurança se relaciona com a previsão? A previsão dá a demanda esperada; o estoque de segurança cobre o erro dessa previsão e a variação do lead time. Quanto pior a acurácia ou mais volátil o prazo de entrega, maior o estoque de segurança necessário para o mesmo nível de serviço. Melhorar a previsão é uma das formas de reduzir estoque parado sem perder disponibilidade.

Preciso de cientista de dados para começar? Não para começar. Um MVP com o forecast nativo do Power BI e políticas de estoque em DAX entrega valor sem cientista de dados. A ciência de dados entra quando você escala para previsão por SKU com variáveis externas. Começar simples e provar valor primeiro é quase sempre a decisão mais sensata.

Que licença do Power BI eu preciso para publicar o painel de previsão? Para compartilhar, cada consumidor precisa de Power BI Pro ou PPU, que são licenças por usuário, ou o conteúdo precisa estar em capacidade dedicada (SKUs Premium P ou de capacidade Fabric F). A escolha depende do número de usuários e do volume de dados. Confirme sempre os preços atuais na fonte oficial da Microsoft, pois variam por contrato e moeda.

Quanto tempo até ter uma previsão utilizável? Com histórico organizado, um MVP no Power BI sai em poucas semanas. O gargalo raramente é o modelo; é a qualidade e a organização do dado de entrada. Investir primeiro em engenharia de dados e governança encurta o caminho mais do que trocar de algoritmo.

Previsão boa é a que vira decisão de compra#

Previsão de demanda logística não é um número mágico, é uma política de estoque sustentada por dado organizado, medida contra o realizado e ajustada com contexto humano. O Power BI resolve a visualização e o MVP; Azure ML e Fabric entram quando a escala e as variáveis externas justificam. O que amarra tudo é governança, sustentação e honestidade sobre os limites.

Se você quer estruturar a previsão de demanda da sua operação sem cair no achismo nem no exagero de engenharia, fale com a gente. A gente ajuda a montar o caminho certo para o seu volume e a sua realidade.