GESTÃO & DECISÃO
7 perguntas antes de contratar uma solução de forecast
Fornecedores de forecast mostram demos com dados limpos, algoritmos com nomes impressionantes e dashboards que parecem ter todas as respostas. As perguntas que realmente importam não aparecem na apresentação — e quem não as faz antes de contratar as descobre depois, da pior forma.
Tempo de leitura: 12 min
O problema com as demos de forecast
Toda demo de solução de forecast parece funcionar. O fornecedor escolhe um conjunto de dados históricos — geralmente limpos, bem comportados, com sazonalidade clara e poucos outliers. Roda o modelo. Mostra o gráfico de previsão versus realização. O erro é baixo, os números são impressionantes, a interface é bonita.
O que a demo não mostra é como o sistema se comporta com os seus dados. Com o histórico de vendas que tem lacunas, produtos com lançamento recente sem histórico suficiente, SKUs descontinuados que ainda aparecem nas tabelas, clientes que compraram de forma irregular nos últimos três anos. Não mostra o que acontece quando um modelo falha em um período crítico. Não mostra quem é responsável por investigar o erro e como o sistema permite fazer isso.
A distância entre o que a demo mostra e o que o sistema entrega no ambiente real da empresa é onde a maioria dos projetos de forecast fracassa. E essa distância é previsível — se as perguntas certas forem feitas antes da assinatura do contrato.
Pergunta 1: Com quantos meses de histórico o modelo funciona bem?
A resposta honesta para essa pergunta elimina muitas opções de mercado antes mesmo de chegar à demo técnica.
Modelos de previsão de demanda com sazonalidade exigem, no mínimo, 24 meses de histórico por SKU para capturar dois ciclos sazonais completos. Modelos que usam técnicas de machine learning para identificar padrões complexos funcionam melhor com 36 a 48 meses. Modelos bayesianos conseguem operar com histórico mais curto, mas com intervalos de confiança maiores.
Se o fornecedor afirma que o modelo funciona bem com 6 ou 12 meses de histórico, a próxima pergunta é: quais algoritmos são usados para produtos com esse volume de dados, e quais são as métricas de erro esperadas nessas condições? Se a resposta for vaga, o modelo provavelmente usa suavização exponencial simples ou média móvel — técnicas que qualquer planilha Excel executa com a mesma qualidade.
Para produtos com histórico curto — lançamentos recentes, novos canais, categorias novas — a pergunta específica é: o sistema oferece métodos alternativos para esses SKUs, como analogia com produtos similares ou entrada de premissas manuais com rastreabilidade? A incapacidade de lidar com novos produtos de forma estruturada é uma limitação relevante em qualquer portfólio em crescimento.
Pergunta 2: Como o sistema mede e reporta o próprio erro?
Um sistema de forecast que não mede sua própria precisão não é gerenciável. Mas a forma como o erro é medido importa tanto quanto o fato de que ele é medido.
MAPE (Mean Absolute Percentage Error) é a métrica mais divulgada. É também a que os fornecedores mais abusam nas apresentações comerciais, porque permite selecionar o subconjunto de SKUs onde o modelo performou melhor e apresentar essa média como o resultado geral. Um MAPE de 8% divulgado em uma demo pode corresponder a um MAPE real de 28% quando calculado sobre o portfólio completo do cliente.
As perguntas que importam sobre métricas de erro:
- O MAPE é calculado sobre todos os SKUs ativos, ou apenas sobre os que têm previsão? SKUs excluídos do modelo de previsão inflam artificialmente a métrica de acurácia.
- O sistema calcula Bias (direção do erro)? Um MAPE de 15% com Bias consistentemente positivo significa que o modelo sistematicamente superestima — o que cria um perfil de excesso de estoque previsível e evitável.
- Há WMAPE (MAPE ponderado por volume ou receita)? O MAPE simples trata um SKU de R$ 500/mês igual a um SKU de R$ 500.000/mês. O WMAPE corrige isso e dá uma leitura mais realista do impacto financeiro do erro.
- O sistema mostra o erro por SKU, não apenas a média geral? A média esconde os problemas. O planejador precisa ver quais produtos têm erro acima de 30%, 40%, 50% — e investigar por quê.
Pergunta 3: O sistema explica por que chegou àquela previsão?
Esta é a pergunta que separa sistemas auditáveis de caixas-pretas — e é a que menos aparece nas avaliações técnicas porque os fornecedores raramente a colocam em evidência.
Quando o sistema prevê 1.200 unidades de um SKU para o próximo mês, o planejador precisa conseguir responder: esse número veio de qual modelo? Com qual histórico? Qual é o peso dado à sazonalidade do período? Há alguma variável exógena incorporada — como evento de mercado, promoção planejada ou comportamento de cliente específico?
Sem essa rastreabilidade, o planejador tem duas opções quando discorda da previsão: aceitar o número sem questionar, ou substituí-lo por um número próprio sem base metodológica. Nos dois casos, o sistema não está sendo usado da forma que deveria.
Auditabilidade não é um diferencial de nicho — é o que permite que o sistema seja questionado, calibrado e melhorado ao longo do tempo. Sistemas que não expõem a lógica da previsão não aprendem com os erros do usuário, e o usuário não consegue aprender com os erros do sistema.
| Característica | Sistema Caixa-Preta | Sistema Auditável |
|---|---|---|
| Transparência do modelo | Resultado visível, lógica oculta | Resultado + metodologia + parâmetros visíveis |
| Resposta ao erro | “O modelo errou” — sem caminho de diagnóstico | É possível identificar qual premissa estava errada |
| Confiança do planejador | Baixa — o número “aparece”, sem explicação | Alta — o planejador pode verificar e questionar |
| Calibração ao longo do tempo | Depende do vendor; ciclos longos | Pode ser ajustada pelo próprio usuário com base em diagnóstico |
| Adoção sustentada | Tendência de abandono após primeiro erro relevante | Resistente a erros porque o processo de correção existe |
Pergunta 4: Como o sistema lida com produtos sem histórico?
Toda empresa tem lançamentos de produto. Toda empresa abre novos canais. Toda empresa tem clientes que começaram a comprar recentemente. Para esses casos, não há histórico de demanda — e modelos puramente estatísticos, que dependem de padrão histórico, não têm nada para trabalhar.
As abordagens que os sistemas usam para esse cenário variam muito em sofisticação e utilidade prática:
- Analogia por produto similar: o sistema identifica produtos com perfil de demanda próximo ao novo SKU (mesma categoria, mesmo cliente, mesmo canal) e usa o padrão histórico desses produtos como proxy. Funciona bem quando o produto similar é bem escolhido e o critério de seleção é transparente.
- Premissa manual com rastreabilidade: o planejador insere uma estimativa de demanda para os primeiros meses, com justificativa registrada no sistema. À medida que o histórico real se acumula, o modelo passa a usar os dados reais progressivamente. O registro da premissa original permite comparar com a realização.
- Combinação de sinais externos: dados de mercado, histórico de produtos similares de concorrentes, dados de pesquisa de intenção de compra. Requer fontes externas e integração mais complexa.
O que o sistema não deveria fazer — mas muitos fazem — é simplesmente excluir os novos SKUs do processo de forecast e deixá-los para gerenciamento manual indefinidamente. Isso cria uma classe de produtos sem cobertura metodológica que tende a crescer ao longo do tempo.
Pergunta 5: O sistema é validado por walk-forward ou por backtesting simples?
Essa pergunta é técnica — e é exatamente por isso que poucos a fazem. Mas a diferença entre as duas abordagens de validação determina se o número de acurácia apresentado pelo fornecedor corresponde à realidade ou é uma construção favorável.
Backtesting simples: o modelo é treinado com o histórico completo disponível e depois testado contra uma parte desse mesmo histórico. O problema é que o modelo já “viu” os dados do período de teste durante o treinamento. A acurácia resultante é artificialmente alta — muito melhor do que seria em condições reais de uso prospectivo.
Walk-forward validation (ou validação prospectiva): o modelo é treinado apenas com os dados disponíveis até um ponto no tempo, e então testado contra o período imediatamente seguinte — que ele nunca viu. Esse processo é repetido em múltiplos períodos, avançando progressivamente. O resultado é uma estimativa realista de como o modelo vai performar quando aplicado a períodos futuros reais.
A diferença de acurácia entre backtesting simples e walk-forward costuma ser de 15 a 30 pontos percentuais. Um sistema que apresenta MAPE de 8% por backtesting pode ter MAPE real de 25% a 35% quando medido prospectivamente com os dados do cliente.
Pergunta 6: O que acontece quando o modelo erra significativamente?
Não existe modelo de forecast que não erre. A diferença entre sistemas que geram valor por anos e sistemas que são abandonados em seis meses não está na taxa de acerto — está no processo que existe quando o erro acontece.
As perguntas específicas para esse cenário:
- O sistema tem alertas de erro? Quando um SKU tem MAPE acima de um threshold definido por um período consecutivo, o sistema avisa o planejador? Ou o erro precisa ser descoberto manualmente na revisão periódica?
- Há um processo estruturado de diagnóstico de erro? O planejador consegue ver, para aquele SKU específico, o histórico de previsões versus realizações, o modelo usado em cada período e os parâmetros aplicados? Ou o diagnóstico exige suporte do fornecedor?
- O fornecedor tem SLA de resposta para erros de modelo? Se um erro de forecast relevante é identificado em uma sexta-feira antes do fechamento de um ciclo de compras, qual é o tempo de resposta? Quem recalcula? Com que prazo?
- O sistema permite override manual com rastreabilidade? Quando o planejador discorda do número do modelo e quer ajustar, o sistema registra o ajuste, quem o fez e qual foi a justificativa? Esse registro é essencial para aprendizado posterior.
Um sistema que não tem resposta clara para essas perguntas vai gerar dependência do suporte do fornecedor nos momentos mais críticos — que são exatamente os momentos em que o erro tem maior impacto.
Pergunta 7: Qual é o custo total de propriedade nos primeiros 24 meses?
O preço da licença ou da assinatura mensal raramente representa o custo total de uma solução de forecast. Os componentes que habitualmente não aparecem na proposta comercial inicial:
| Componente de custo | Aparece na proposta inicial? | Magnitude típica |
|---|---|---|
| Licença / assinatura | Sim | Base da comparação |
| Implantação e configuração inicial | Às vezes | 50% a 200% da licença anual |
| Integração com ERP (conectores, horas de consultoria) | Raramente | R$ 30K a R$ 200K dependendo do ERP e do escopo |
| Tratamento e limpeza de dados históricos | Raramente | R$ 20K a R$ 80K em projetos típicos |
| Treinamento e onboarding da equipe | Às vezes (como item genérico) | R$ 15K a R$ 50K |
| Customizações e ajustes pós-implantação | Quase nunca | Variável; pode exceder o custo de licença no primeiro ano |
| Horas internas de TI e supply chain alocadas ao projeto | Nunca | 100 a 500 horas no primeiro ano |
Pedir um custo total de propriedade detalhado para os primeiros 24 meses, incluindo todos esses componentes, é uma forma rápida de avaliar a transparência do fornecedor. Os que têm boas respostas para essa pergunta são, geralmente, os que têm boas respostas para as perguntas anteriores.
A pergunta que não está na lista — mas deveria estar
As sete perguntas acima são técnicas e comerciais. Há uma oitava que é estratégica, e que raramente aparece em processos de seleção de forecast porque parece óbvia demais para ser feita explicitamente:
O que muda no processo de tomada de decisão da minha empresa se esse sistema funcionar como prometido?
Parece uma pergunta simples. Mas quando ela é feita de forma honesta, revela se o projeto tem sponsor executivo real, se o processo de S&OP vai ser ajustado para incorporar os outputs do modelo, se o gerente de compras vai mudar os parâmetros de reposição com base nos resultados, e se há alguém com autoridade para fazer essas mudanças acontecerem.
Sistemas de forecast não geram valor por si mesmos. Eles geram valor quando as decisões de planejamento mudam em função dos resultados que produzem. Um sistema tecnicamente superior, em uma empresa onde o processo de planejamento não vai mudar, entrega o mesmo resultado que uma planilha Excel mais cara.
A pergunta sobre mudança de processo deveria ser feita antes da seleção da ferramenta — não como uma formalidade, mas para verificar se o projeto tem as condições de sucesso que precisam existir independentemente de qual fornecedor for escolhido.
O que os melhores processos de seleção têm em comum
Empresas que contratam soluções de forecast e obtêm resultados consistentes geralmente têm em comum três práticas no processo de seleção que separam avaliações sérias de processos que terminam com arrependimento:
Piloto com os próprios dados. Antes de assinar qualquer contrato, exigem que o fornecedor rode o modelo com uma amostra real do histórico da empresa — incluindo os SKUs problemáticos, os períodos com lacunas de dado, os produtos de lançamento recente. A demo com dados do fornecedor não tem validade diagnóstica.
Definição de critério de sucesso antes do piloto. Acordam com o fornecedor, antes de começar, qual é o MAPE mínimo aceitável, em que condições de dado, medido por walk-forward, para quais categorias de SKU. Sem esse critério pré-definido, qualquer resultado pode ser justificado como “dentro do esperado”.
Envolvimento do planejador na avaliação técnica. A pessoa que vai usar o sistema diariamente participa da avaliação — não apenas o gerente que vai assinar o contrato. O planejador identifica rapidamente o que a demo não mostra: a interface é intuitiva para o fluxo de trabalho real? É possível investigar erros sem suporte? As exceções são fáceis de identificar?
O custo das perguntas não feitas
Projetos de forecast que não têm resposta para as sete perguntas desta lista antes da contratação tendem a gerar um padrão de resultado reconhecível: implantação que demora o dobro do prometido, adoção parcial pelo time de planejamento, relatórios de acurácia que ninguém questionou porque ninguém entendeu como eram calculados, e uma decisão de renovação de contrato que é adiada indefinidamente porque “o projeto ainda não foi totalmente implementado”.
O custo acumulado desse ciclo — em horas internas, em consultoria, em decisões de planejamento tomadas sem a informação que o sistema deveria fornecer — raramente é calculado. Mas ele existe. E ele costuma superar o custo da licença que parecia razoável na proposta original.
Perguntas difíceis antes de contratar são mais baratas do que descobertas desagradáveis depois de implantar.
Antes de contratar um sistema de forecast, vale saber exatamente o que você está comprando.
O EpiphanyAI é a plataforma de IA Auditável da Direção e Sentido. Os modelos de previsão são validados por walk-forward, o erro é visível por SKU em múltiplas métricas, e a lógica de cada previsão pode ser auditada pelo planejador — sem depender de suporte do fornecedor para entender o que aconteceu.
Nem todo diretor de supply chain concordaria com o que está escrito aqui. Na semana que vem, o contraponto.
Continue lendo:
- Contraponto: Fiz as 7 perguntas. O fornecedor respondeu tudo bem. O projeto ainda assim fracassou.
- O que é IA Auditável — e por que você deveria se importar
- MAPE, MAE, WMAPE e Bias: o que os números de forecast realmente dizem
- Como integrar IA ao ERP sem substituí-lo
- S&OP: do Excel ao workflow digital
Direção e Sentido Estratégia e Inovação — Mais de 20 anos transformando dados em decisões.