GESTÃO & DECISÃO
Fiz as 7 perguntas. O fornecedor respondeu tudo bem. O projeto ainda assim fracassou.
As perguntas certas na seleção de fornecedor são necessárias. Não são suficientes. O que acontece depois da assinatura do contrato depende de variáveis que nenhuma pergunta de due diligence consegue prever — e que determinam o resultado com muito mais força do que a qualidade técnica do sistema escolhido.
Tempo de leitura: 12 min
O fornecedor que tem resposta para tudo
Há um perfil de fornecedor que emerge naturalmente quando o mercado começa a circular listas de perguntas técnicas a fazer antes de contratar: o fornecedor que treinou as respostas.
Walk-forward validation? Sim, usamos walk-forward. Bias reportado por SKU? Claro, temos o dashboard de Bias. WMAPE disponível? Está na versão standard. Piloto com os seus dados? Absolutamente, é parte do nosso processo. Custo total de propriedade nos primeiros 24 meses? Temos um template para isso.
Todas as respostas corretas. Todas as caixas marcadas. Contrato assinado. E seis meses depois, o planejador ainda está usando o Excel em paralelo porque “o sistema não captura bem a nossa sazonalidade”, o time de TI ainda está finalizando a integração com o ERP, e o dashboard de Bias existe mas ninguém sabe interpretar o que ele mostra.
O problema não foi a pergunta errada. Foi não saber o que fazer com as respostas certas.
O que “walk-forward validation” significa na proposta versus na prática
O artigo anterior explica corretamente a diferença entre backtesting e walk-forward: backtesting treina o modelo com dados que incluem o período de teste; walk-forward garante que o modelo nunca viu os dados do futuro que está prevendo. A distinção é real e importante.
O que o artigo não diz é que confirmar que o fornecedor usa walk-forward não é o fim da investigação — é o início. As perguntas que precisam seguir:
Walk-forward com qual janela de teste? Um modelo validado com janela de um mês vai mostrar acurácia diferente de um validado com janela de seis meses. A janela curta favorece o modelo. A janela longa revela como ele se comporta quando as condições de mercado mudam.
Walk-forward com retreinamento a cada período ou com modelo fixo? Se o modelo é retreinado a cada passo da validação, o resultado é mais realista mas também mais custoso computacionalmente — e alguns fornecedores fazem walk-forward com modelo fixo porque é mais rápido de rodar e produz número melhor para apresentar.
Walk-forward sobre quais SKUs? Se a validação excluiu os SKUs com histórico curto, com sazonalidade extrema ou com alta variabilidade — justamente os mais difíceis de prever — o número de acurácia é uma média dos casos fáceis.
Nenhuma dessas perguntas complementares aparece na lista de sete. E sem elas, confirmar que o fornecedor usa walk-forward não garante que o número de acurácia apresentado corresponde ao que o modelo vai entregar no ambiente real da empresa.
Auditabilidade: o que o fornecedor mostra na demo não é o que o planejador usa no dia a dia
A pergunta 3 do artigo — “o sistema explica por que chegou àquela previsão?” — é provavelmente a mais importante da lista. Um sistema que não mostra a lógica da previsão é uma caixa-preta. Quando ele erra, ninguém sabe por onde começar a investigar.
Mas há uma distinção que a pergunta não captura: a diferença entre auditabilidade técnica e auditabilidade operacional.
Auditabilidade técnica significa que a informação existe no sistema — qual modelo foi usado, quais parâmetros, qual histórico, qual peso da sazonalidade. Está lá, acessível a quem sabe onde procurar.
Auditabilidade operacional significa que o planejador que usa o sistema diariamente consegue, em dois ou três cliques, entender por que aquele número específico foi gerado e o que ele precisaria mudar para chegar a um número diferente. Sem precisar abrir ticket de suporte. Sem precisar chamar o analista de dados. No meio da reunião de S&OP, quando o gerente comercial questiona a previsão e o planejador precisa de uma resposta em 30 segundos.
A demo mostra a auditabilidade técnica. O planejador precisa da operacional. Confirmar que “o sistema é auditável” sem testar a auditabilidade operacional no fluxo real de trabalho do usuário é marcar uma caixa sem verificar o que está dentro dela.
| Tipo de auditabilidade | O que significa | Como testar antes de contratar |
|---|---|---|
| Técnica | A informação sobre o modelo existe e é acessível | Perguntar onde está — na demo, navegar até lá sem ajuda do vendedor |
| Operacional | O planejador consegue entender e explicar a previsão sem suporte | Pedir que o planejador da empresa (não o IT) faça esse caminho sozinho durante o piloto |
| Gerencial | O gestor consegue ver padrões de erro e tomar decisão de calibração | Simular uma situação de erro relevante e verificar o processo de diagnóstico de ponta a ponta |
O piloto que confirma o que você já queria acreditar
O artigo recomenda pilotos com os próprios dados. É a prática certa. O risco é o piloto mal estruturado — aquele que foi desenhado, consciente ou inconscientemente, para confirmar a decisão que já estava sendo tomada.
Pilotos de forecast tendem a ser executados no período de maior disponibilidade de dado e menor volatilidade de demanda — porque é quando a empresa tem histórico limpo para compartilhar com o fornecedor e quando o resultado da comparação é mais favorável. O modelo vai bem no piloto. A implantação acontece. O primeiro trimestre de operação real coincide com o pico sazonal, com um lançamento de produto novo e com uma mudança de mix de cliente. O modelo erra mais do que no piloto. O time perde confiança.
Um piloto robusto testa o modelo nas condições mais difíceis, não nas mais favoráveis. Inclui os SKUs com maior variabilidade histórica. Inclui pelo menos um período com ruptura de estoque que distorceu o histórico de demanda. Inclui produtos com sazonalidade extrema. Se o modelo se sai razoavelmente nesses casos, ele vai se sair bem nos casos fáceis. O inverso não é verdade.
O critério de sucesso que ninguém define antes
O artigo menciona definir critério de sucesso antes do piloto como uma das práticas dos melhores processos de seleção. É verdade — e é também a prática menos seguida, porque definir critério de sucesso é desconfortável para as duas partes.
Para o fornecedor, critério de sucesso pré-definido significa que o piloto pode reprovar. É mais seguro deixar o critério vago.
Para o comprador, critério de sucesso pré-definido significa que há um número específico abaixo do qual o projeto não avança — e isso é difícil de sustentar quando há pressão interna para mostrar progresso, quando o orçamento já foi aprovado e quando as conversas com o fornecedor já criaram um compromisso implícito.
O resultado é que a maioria dos pilotos termina com uma avaliação qualitativa: “o resultado foi promissor”, “há potencial”, “precisamos de mais tempo para calibrar”. Nenhuma dessas frases é um critério de sucesso. São formas de adiar a decisão difícil enquanto o projeto avança.
Um critério de sucesso real é específico e binário: WMAPE abaixo de X% para os 50 SKUs de maior faturamento, medido por walk-forward com janela de três meses, até a data Y. Se não atingiu, o projeto não avança. Simples de enunciar. Quase impossível de manter na prática sem patrocinador executivo que suporte a decisão de não avançar.
O que acontece depois da assinatura — e que nenhuma pergunta cobre
As sete perguntas do artigo anterior cobrem o processo de seleção. O que determina o resultado do projeto, na maioria dos casos, acontece depois da seleção.
A qualidade da equipe de implantação do fornecedor — que frequentemente não é a equipe que fez a demo. O engajamento do planejador que vai usar o sistema — que frequentemente não participou da seleção. A prioridade que o time de TI vai dar à integração com o ERP quando concorrer com outros projetos. A disposição do gerente de supply chain de questionar o modelo quando ele errar, em vez de simplesmente baixar a tarifa de confiança no sistema inteiro.
Esses fatores não aparecem em nenhuma pergunta de due diligence porque não são perguntas para o fornecedor — são perguntas para a própria organização. E são as que mais frequentemente determinam o resultado.
- Quem internamente é dono do projeto após a assinatura? Se a resposta for “TI cuida da parte técnica e supply chain cuida da parte operacional”, não há dono. Há dois meios-donos que vão se culpar mutuamente quando algo der errado.
- O planejador que vai usar o sistema sabe que está comprando? Sistemas de forecast comprados por diretores e implementados por analistas que não foram consultados têm taxa de adoção consistentemente menor do que os casos onde o usuário participou da seleção.
- O que acontece quando o modelo errar relevantemente pela primeira vez? Se a resposta organizacional for abandonar o sistema, o projeto vai durar até o primeiro erro grande. Se a resposta for investigar, calibrar e aprender, o projeto tem chance de amadurecer.
As perguntas que faltam na lista
Não ao fornecedor. À própria organização, antes de iniciar qualquer processo de seleção.
- O processo de planejamento atual vai mudar em função dos outputs do modelo — ou o modelo vai ser mais um dado que entra na reunião e compete com intuição e hierarquia? Se o processo não muda, o modelo não entrega valor. A ferramenta é irrelevante.
- Há tolerância organizacional para os primeiros meses de erro — quando o modelo ainda está sendo calibrado com os dados reais da empresa? Todo modelo novo erra mais no início. Se o primeiro erro grande gera abandono, o projeto não vai chegar ao estado de valor.
- A empresa já tentou antes? Se sim, o que falhou na tentativa anterior não foi o sistema — foi algo no contexto organizacional. Esse algo precisa ser identificado e endereçado antes de tentar de novo com uma ferramenta diferente.
As sete perguntas do artigo anterior continuam válidas. Fazê-las ao fornecedor sem antes responder essas três para a própria organização é otimizar a escolha do instrumento sem verificar se a orquestra está pronta para tocar.
A pergunta mais importante antes de contratar forecast não é para o fornecedor. É para a sua própria organização.
O EpiphanyAI é a plataforma de IA Auditável da Direção e Sentido. Antes de qualquer demo, fazemos as perguntas que ajudam a entender se o projeto tem as condições para funcionar — não apenas se o sistema tem as funcionalidades.
Continue lendo:
- Leia primeiro: 7 perguntas antes de contratar uma solução de forecast
- S&OP: do Excel ao workflow digital
- MAPE, MAE, WMAPE e Bias: o que os números de forecast realmente dizem
- O que é IA Auditável — e por que você deveria se importar
Direção e Sentido Estratégia e Inovação — Mais de 20 anos transformando dados em decisões.