Problemas e soluções comuns

Geralmente causada por colisões de chaves compostas — se dois registros compartilham o mesmo identificador exclusivo, um substitui o outro.

Também pode ocorrer se os critérios de filtro no mapeamento de dados excluírem registros que você espera ver.

Os pedidos atendidos ou removidos entre as execuções do relatório desaparecerão na próxima atualização, mas ainda poderão aparecer nas exceções geradas a partir dos dados do dia anterior.

Pedidos recém-criados não aparecerão até a próxima atualização de dados.

O sistema filtrará automaticamente para o produto principal. Somente os produtos presentes no arquivo mestre do produto serão incluídos na previsão. No entanto, se uma grande porcentagem do seu arquivo de entrada estiver fora do escopo (por exemplo, mais de 50% das linhas), isso indica que a exportação de origem precisa ser restrita.

Verifique a taxa de cobertura do seu produto regularmente. Depois de cada carregamento de dados, verifique qual porcentagem de produtos em seus arquivos de entrada de vendas e previsões corresponde ao produto mestre. Se a cobertura cair abaixo de 80%, investigue se o escopo da exportação de origem mudou ou se o produto principal precisa ser atualizado.

Out-of-scope produtos nas entradas do plano podem causar totais inflacionados. Se seus arquivos EDI ou SIOP incluírem produtos de outras fábricas, o sinal agregado de previsão será maior do que deveria. Certifique-se de que os arquivos de entrada do plano sejam filtrados para o mesmo escopo do produto principal antes de serem carregados.

Verifique a data e hora da exceção — se ela tiver mais de um dia, a recomendação pode estar obsoleta.

Se a recomendação estiver claramente errada (por exemplo, ignorar um pedido grande visível no gráfico), forneça feedback usando o polegar para baixo e relate a exceção específica à sua equipe de suporte.

A data de impacto mostra quando o problema de estoque começa (por exemplo, quando a falta de estoque começa ou o excesso excede o limite).

A data de validade deve levar em conta o prazo de entrega para que você tenha tempo de agir antes que o problema se materialize. Se o Act By for igual à data de impacto, o lead time pode não ser incorporado — informe isso à sua equipe de suporte.

Muitos volume/inactive produtos de baixo escopo. É difícil para qualquer modelo superar uma média simples de produtos com demanda esparsa e intermitente. Use uma regra de pré-processamento para definir o escopo da previsão para produtos com histórico de demanda significativo (por exemplo, pelo menos 6 meses de demanda diferente de zero).

Treinamento sobre histórico obsoleto ou contaminado. Se seu histórico de pedidos remonta a muitos anos, os antigos padrões de demanda podem não refletir a realidade atual. Considere uma regra de pré-processamento para limitar o histórico de treinamento aos 3 a 5 anos mais recentes ou para substituir períodos anômalos (por exemplo, COVID) por valores normalizados.

Aumentos de demanda em pedidos únicos. Um único pedido grande em massa pode criar uma falsa tendência ascendente nos dados de treinamento. Use uma regra de pré-processamento para limitar valores anômalos de demanda mensal a um múltiplo da média final (por exemplo, 5x).

Regras de consenso aplicadas na direção errada. O agente LLM pode interpretar mal a linguagem das regras. “Diminuir em 27%" pode ser aplicado como um aumento. Sempre valide a produção consensual em relação à linha de base comparando produtos e meses específicos. Use linguagem de multiplicação explícita (“multiplicar por 0,725") em vez de linguagem direcional (“diminuir em 27,5% “).

O modelo é treinado em um período de crescimento. Se os últimos anos mostraram um crescimento que não continua, o modelo extrapola uma tendência que não existe mais.

As regras de consenso estão aumentando os ajustes. Várias regras que aumentam a previsão (viés de falta de estoque, aumento de tendência, aumento sazonal) podem agravar. Verifique quais regras estão ativas e verifique se todas se aplicam aos mesmos produtos.

Deleted/discontinued produtos ainda no escopo. Produtos com demanda inativa que ainda estão sendo previstos apresentarão previsões excessivas sistemáticas.

Os sinais externos de previsão não estão sendo incorporados. Se você tiver informações do plano (por exemplo, previsões de clientes EDI, planos de produção de SIOP) carregadas, mas suas regras de consenso não as aplicarem, a previsão usa como padrão a linha de base estatística, que pode não capturar os sinais de demanda que seus planejadores veem. Verifique se as regras de consenso estão realmente modificando a saída comparando a exportação com a ConsensusForecast exportação Forecast (linha de base). Se forem idênticas, as regras não são válidas.

Combinações esparsas de produto x site reduzindo o agregado. Se você fizer previsões com base na granularidade produto×site, mas muitas combinações tiverem demanda zero ou quase zero, o modelo produzirá pequenas previsões diferentes de zero para combinações inativas. Eles não somam muito individualmente, mas, coletivamente, arrastam a previsão total abaixo dos reais. Use uma regra de pré-processamento para excluir combinações com histórico de demanda insuficiente ou use o preenchimento zero condicional nas entradas do seu plano para sinalizar explicitamente “nenhuma demanda esperada” para combinações inativas.

O modelo não capturou uma tendência recente de crescimento. Os modelos estatísticos avaliam os dados históricos. Se sua empresa cresceu significativamente nos últimos meses, mas o modelo tem anos de histórico de menor volume, ela ficará aquém da tendência. Isso geralmente melhora com o tempo, à medida que o modelo acumula dados mais recentes. Nesse ínterim, considere uma regra de consenso que usa uma média final de valores reais recentes como base para semanas externas de previsão.

Year-over-year incompatibilidade de sazonalidade. Se o padrão de demanda deste ano for diferente dos anos anteriores (por exemplo, rampa sazonal anterior, lançamentos de novos produtos), o modelo poderá subestimar durante o período divergente. Verifique se o subviés está concentrado em semanas ou meses específicos que diferem do padrão do ano anterior.

Sinais externos só ajudam a curto prazo. Se você tiver regras consensuais que incorporem previsões de clientes (EDI) nas primeiras semanas, a precisão será visivelmente melhor no curto prazo e diminuirá quando as regras deixarem de ser aplicadas. Isso é esperado — considere estender as regras para cobrir mais semanas com uma abordagem combinada (por exemplo, 50/50 combinação de sinal externo e linha de base para semanas de médio prazo).

A linha de base reverte para uma média de longo prazo em horizontes mais longos. Os modelos estatísticos se tornam menos confiantes em horizontes mais longos e tendem à média histórica. Se a demanda recente estiver acima da média histórica, as últimas semanas parecerão pouco tendenciosas. Esse é um comportamento do modelo, não um problema de configuração.

A volatilidade da demanda torna horizontes mais longos inerentemente mais difíceis. Se sua demanda tiver alta variabilidade semanal (coeficiente de variação > 0,5), até mesmo um modelo perfeito mostrará alto erro em horizontes maiores. Concentre a avaliação da precisão nas primeiras 3 a 4 semanas, que é a janela de planejamento acionável para a maioria das operações.

O sinal externo pode não cobrir produtos suficientes. O EDI ou as previsões de clientes normalmente cobrem apenas um subconjunto do seu catálogo de produtos (geralmente de 30 a 50%). Produtos sem sinal externo ainda usam a linha de base. Verifique sua taxa de cobertura — se estiver abaixo de 50%, o impacto na precisão agregada será limitado.

O sinal externo pode não ser preciso o suficiente para ajudar. Meça a precisão da previsão externa de forma independente antes de usá-la em regras. Se seu WAPE for pior do que a linha de base, incorporá-lo prejudicará em vez de ajudar. Considere limitar a regra a sites ou produtos específicos em que o sinal externo é comprovadamente melhor (por exemplo, WAPE ponderado por volume abaixo de 50%).

O sinal externo não informa zeros. Muitos sistemas EDI só enviam registros de produtos com pedidos ativos — eles omitem produtos com demanda zero em vez de relatar explicitamente zero. Se sua regra de consenso disser “quando EDI = 0, defina a previsão como 0”, ela nunca será acionada porque não há zero registros. Você precisa gerar registros zero sintéticos no pré-processamento para combinações de produto x site que não tenham sinal externo e nenhum histórico de vendas recente.

A precisão do sinal externo varia de acordo com o horizonte. As previsões dos clientes geralmente são mais precisas para a próxima semana (essencialmente pedidos confirmados) e se degradam rapidamente. Uma regra que usa o sinal externo diretamente durante todas as semanas pode prejudicar a precisão em horizontes mais longos. Considere uma abordagem em camadas: substituição direta nas semanas 1 a 3, combinada nas semanas 4 a 6, linha de base somente nas semanas 7 ou mais.

A regra pode ter sido substituída por uma regra de maior prioridade. As regras são aplicadas em ordem de prioridade. Uma regra posterior pode desfazer uma anterior. Verifique a ordem das regras.

A condição da regra pode não corresponder a nenhum produto. Se a regra fizer referência a um atributo do produto (por exemplo, product_group_id) que não esteja nos metadados do item, ela silenciosamente não corresponderá a nada.

A linguagem das regras foi mal interpretada. O agente LLM gera código a partir da linguagem natural. Um fraseado ambíguo pode produzir resultados inesperados. Seja o mais específico e literal possível. Use nomes de campo exatos, multiplicadores explícitos e condições claras.

Incompatibilidade de dimensões na junção. O mecanismo de consenso une as entradas do plano à linha de base em colunas de dimensão (ID do produto, ID do site, data). Se os nomes das colunas forem diferentes entre as entradas da linha de base e do plano (por exemplo, a linha de base usa item_id enquanto o EDI usa product_id), a junção não produz correspondências e todas as regras seguem o padrão da linha de base. Verifique se o mapeamento de dimensões em sua configuração de fluxo de dados mapeia corretamente entre os dois esquemas.

Incompatibilidade de formato de data. A linha de base pode armazenar datas como 2026-03-02, enquanto as entradas do plano as armazenam como 2026-03-02. T00:00:00.000Z Se a associação exigir uma correspondência exata, as datas com reconhecimento de fuso horário e sem fuso horário não corresponderão. Verifique se as colunas de data foram convertidas no mesmo formato antes de se juntarem.

As entradas do plano não foram carregadas. Verifique se os arquivos de entrada do seu plano (EDI, SIOP etc.) foram ingeridos com sucesso. Verifique as contagens de registros no sistema — se elas mostrarem zero linhas para uma entrada do plano, o arquivo pode ter falhado ao carregar.

O consenso forecast_id corresponde à linha de base forecast_id. Se ambas as exportações compartilharem o mesmo forecast_id, o mecanismo de consenso produzirá uma cópia direta da linha de base sem processamento. Isso indica um problema no nível do sistema — entre em contato com sua equipe de suporte com o forecast_id e o demand_plan_run_id.

A condição do site/product filtro pode fazer referência à coluna errada. Se sua regra disser “aplicar a sites em [lista]”, mas o código gerado verificar uma coluna que não existe ou tem valores diferentes, o filtro pode passar silenciosamente todas as linhas. Verifique pontualmente alguns produtos específicos que NÃO devem ser afetados pela regra.

A ordem de prioridade da regra pode ser invertida. As regras são aplicadas como uma cadeia em que as regras posteriores substituem as anteriores. Se uma regra ampla (por exemplo, “usar linha de base para tudo”) for aplicada após uma regra específica (por exemplo, “usar EDI para esses 50 sites”), a regra ampla desfará a específica. Certifique-se de que suas descrições de regras indiquem claramente a ordem de prioridade.

Adicione uma regra de arredondamento como etapa final do consenso. Uma regra simples de “arredondar para o número inteiro mais próximo” aplicada após todas as outras regras de consenso limpará os valores fracionários. Valores abaixo de 0,5 serão arredondados para zero, o que é apropriado para combinações de demanda muito baixa.

Considere o arredondamento para quantidades operacionais. Se seus produtos forem enviados em tamanhos de embalagem padrão (por exemplo, caixas de 12, paletes de 48), arredondar para o tamanho de embalagem válido mais próximo pode melhorar a usabilidade e a precisão da previsão. Isso requer dados de tamanho do pacote em seu produto mestre. Compartilhe seus dados de MOQ ou tamanho do pacote com sua equipe de suporte para explorar essa opção.

Verifique a granularidade. Um produto pode ter 52 semanas de demanda no nível do produto, mas apenas 3 semanas em qualquer combinação individual de produto x local. Um limite mínimo de histórico aplicado no nível do produto × site excluirá a maioria das combinações. Em vez disso, considere aplicar o limite no nível do produto ou reduzi-lo significativamente.

Teste antes da implantação. Antes de ativar uma regra de pré-processamento, conte quantas combinações de produto x site passam pelo filtro versus seu total atual. Se mais de 20% forem excluídos, é provável que a regra seja muito agressiva. Comece com um limite moderado e aumente gradualmente.