O forecast não erra sozinho: como dados ruins sabotam sua previsão

Antes de questionar o modelo de previsão, questione os dados que o alimentam. A maioria dos erros de forecast tem origem não no algoritmo, mas na qualidade do histórico que ele recebe. Este artigo mapeia os 5 problemas de dados mais comuns na indústria brasileira — e mostra como diagnosticá-los antes que se transformem em excesso de estoque ou ruptura.

O princípio que todos conhecem e ninguém aplica

“Garbage in, garbage out” é talvez o clichê mais repetido da tecnologia da informação. Na prática, poucas empresas industriais o aplicam ao planejamento de demanda. O ERP registra pedidos, faturamentos, devoluções e transferências — mas o dado que chega ao modelo de previsão raramente é o mesmo que está no sistema transacional.

Entre o registro no ERP e a entrada no forecast, o dado percorre um caminho que em muitas empresas se parece com o seguinte: extração manual em planilha → ajustes pelo PCP (remoção de “distorções” baseada em memória pessoal) → consolidação por família de produto (com critérios que mudam a cada ciclo) → envio para o modelo ou planilha de previsão.

Em cada uma dessas etapas, informação é perdida, distorcida ou inventada. O modelo de previsão — seja uma média móvel simples ou um ensemble de machine learning sofisticado — recebe um histórico que não reflete o que realmente aconteceu. E entrega uma previsão que reflete essa distorção.

Um estudo do Institute of Business Forecasting (IBF) estimou que até 40% do erro de forecast em empresas industriais pode ser atribuído a problemas de qualidade de dados — não à escolha do modelo. Isso significa que trocar o algoritmo sem limpar a base é como trocar o motor de um carro com o tanque cheio de água.

Os cinco sabotadores silenciosos

Identificamos cinco problemas de dados que se repetem em empresas de diferentes setores e portes. Nenhum deles é difícil de diagnosticar. O problema é que raramente alguém procura.

1. Outliers não tratados

Uma venda atípica — uma promoção agressiva, um pedido concentrado de um único cliente, uma antecipação por risco de aumento de preço, uma venda de liquidação — distorce o histórico. Se esse ponto não é identificado e tratado, o modelo incorpora a exceção como se fosse padrão e superestima a demanda futura.

Exemplo concreto: uma indústria de embalagens recebeu um pedido pontual de 400 toneladas de um cliente que normalmente compra 50 por mês. O cliente estava antecipando compra por expectativa de reajuste de preço. Esse pico foi registrado como venda regular. No mês seguinte, o modelo de média móvel de 3 meses projetou demanda 60% acima do normal para aquela família — gerando produção excedente que levou 4 meses para ser consumida, ao custo de R$ 180 mil em capital imobilizado.

O tratamento correto: identificar o outlier, classificá-lo (promoção, antecipação, evento único) e decidir se ele deve ser incluído, excluído ou substituído pelo valor normalizado no histórico que alimenta o modelo. Essa decisão precisa ser documentada — porque o próximo analista que olhar o dado precisa saber o que foi feito e por quê.

2. Zeros que não são zeros

Quando um produto tem demanda registrada como zero em um período, o modelo precisa saber se isso é demanda real zero (o mercado não quis comprar) ou ruptura (a empresa não tinha para vender, então não houve registro de venda — mas a demanda existia).

Se houve ruptura, o zero registrado esconde uma demanda real que não foi atendida. A previsão, sem essa distinção, subestima o futuro. O modelo “aprende” que aquele produto não tem demanda naquele período — quando na verdade tinha, mas não pôde ser atendida.

Esse problema é especialmente grave em indústrias com alto número de SKUs e múltiplos centros de distribuição. Em uma empresa de autopeças com 12.000 SKUs, uma análise interna revelou que 18% dos registros mensais de “demanda zero” eram na verdade rupturas não sinalizadas. A correção desses zeros elevou a acurácia do forecast em 4,3 pontos percentuais de MAPE — sem trocar nenhum modelo.

A solução: cruzar os registros de “venda zero” com os registros de estoque disponível. Se o estoque estava zerado ou abaixo do mínimo no período em que a venda foi zero, é provável que seja ruptura, não falta de demanda. Essa correção é trabalhosa na primeira vez, mas pode ser automatizada para os ciclos seguintes.

3. Granularidade inconsistente

Algumas famílias de produto têm dados diários; outras, apenas mensais. Alguns centros de produção registram vendas por SKU; outros, por grupo de produtos. Alguns canais reportam sell-out; outros, sell-in. Quando o modelo recebe dados com granularidades diferentes sem normalização, os resultados são enviesados para as séries mais granulares — e as séries com menos granularidade são suavizadas artificialmente.

O problema se agrava quando a empresa opera com múltiplos ERPs — cenário comum em empresas que cresceram por aquisição. Cada ERP tem sua própria taxonomia de produtos, seus próprios códigos de centro de custo e sua própria estrutura de dados. A consolidação para fins de forecast exige um trabalho de mapeamento que muitas vezes é feito de forma manual e inconsistente.

A recomendação: definir uma granularidade padrão — por exemplo, família de produto × centro de produção × mês — e normalizar todas as séries para esse padrão antes de alimentar o modelo. Se um centro reporta dados semanais, agregar para mensal. Se outro reporta por SKU, agregar para família. A consistência da granularidade é mais importante do que a granularidade em si.

4. Mudanças de cadastro não rastreadas

Fusão de SKUs, reclassificação de famílias, mudança de unidade de medida, incorporação de linha de um concorrente adquirido — qualquer alteração cadastral que não é refletida no histórico cria descontinuidades. O modelo trata como se dois produtos diferentes fossem o mesmo, ou vice-versa.

Exemplo: uma indústria farmacêutica reclassificou 60 SKUs de uma família para outra como parte de uma reestruturação comercial. O histórico de vendas permaneceu na família antiga. O resultado: a família antiga ficou com histórico inflado (o modelo previa demanda que já não existia ali) e a família nova ficou sem histórico (o modelo não tinha base para prever). Foram dois meses de alocação incorreta até que alguém diagnosticou o problema.

A prevenção é simples mas exige disciplina: toda mudança cadastral que afeta famílias de produto ou centros de produção precisa ser comunicada ao responsável pelo forecast no momento em que acontece — não três meses depois, quando o erro já se materializou no estoque. Sistemas maduros mantêm um log de alterações cadastrais que é automaticamente cruzado com o histórico de demanda.

5. Sazonalidade assumida, nunca validada

Muitas empresas aplicam fatores de sazonalidade porque “sempre foi assim”. Dezembro é forte, janeiro é fraco, Páscoa dá pico em chocolates, inverno puxa aquecedores. Essas premissas podem ter sido verdadeiras há cinco anos. A pergunta é: ainda são?

A sazonalidade muda. Canais digitais alteraram ciclos de compra que eram previsíveis por décadas. A pandemia deslocou picos de consumo que pareciam permanentes. Mudanças climáticas estão alterando padrões sazonais em alimentos e bebidas. O crescimento do e-commerce redistribuiu a demanda ao longo do mês — o “pico de fim de mês” que existia quando 80% das vendas passavam por distribuidores pode ter encolhido significativamente.

Se a sazonalidade não é revalidada com dados dos últimos 2–3 anos, ela vira premissa falsa — uma ficção que parece técnica porque usa números, mas que não reflete mais a realidade. O teste é simples: compare os fatores sazonais que você está usando com os calculados a partir dos dados dos últimos 24 meses. Se a divergência for superior a 10% em algum período, seus fatores estão desatualizados.

Como diagnosticar: um checklist de 10 minutos

Antes de investir em novos modelos ou novas ferramentas, passe 10 minutos respondendo estas perguntas sobre a sua base de dados de forecast. Se a resposta for “não” ou “não sei” para três ou mais, a prioridade não é trocar o modelo — é limpar a base.

1. Outliers: Você tem um processo documentado para identificar e tratar vendas atípicas antes de alimentar o modelo?

2. Rupturas: Seu histórico diferencia “demanda zero” de “estoque zerado”? Existe cruzamento automático entre vendas e posição de estoque?

3. Granularidade: Todos os centros de produção e canais alimentam o modelo na mesma granularidade (família × centro × período)?

4. Cadastro: Existe um log de mudanças cadastrais (fusão de SKUs, reclassificação de famílias) vinculado ao histórico de demanda?

5. Sazonalidade: Os fatores sazonais em uso foram recalculados nos últimos 12 meses com dados reais?

6. Rastreabilidade: Você consegue, para qualquer família de produto, abrir o histórico que alimentou o modelo e verificar se ele é fiel ao que está no ERP?

O que muda quando os dados são auditáveis

A solução não é ter dados perfeitos — perfeição não existe em dados industriais. A solução é ter rastreabilidade sobre a qualidade dos dados que entram no modelo. Isso significa saber, para cada família de produto e cada centro de produção: quantos períodos com dados faltantes existem no histórico, quantos outliers foram detectados e como foram tratados, qual a data do último recadastramento que afetou a série, e se o modelo atual considera ou ignora essas anomalias.

Quando essa rastreabilidade existe, o gestor consegue avaliar não apenas o resultado da previsão, mas a confiabilidade da base que a gerou. Se o modelo projeta 500 toneladas para uma família com 8 outliers não tratados no histórico, a confiança nesse número é diferente de uma projeção de 500 toneladas para uma família com histórico limpo e estável.

Essa distinção — saber em quais previsões confiar mais e em quais confiar menos — é o que separa empresas que operam com estoque de segurança inflado “por precaução” de empresas que calibram o safety stock com base na confiabilidade real do forecast.

---

Leia também: Como 9 abordagens competem para prever sua demanda | Estoque de segurança: onde a maioria erra | Como medir acurácia de forecast