Problemas e soluções comuns

Mais comumente causado 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 os registros que você espera ver.

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

Os 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. Após 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 foi alterado ou se o produto principal precisa ser atualizado.

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

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 a emissão 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 do impacto, o prazo de entrega pode não ser incorporado — informe isso à sua equipe de suporte.

Muitos volume/inactive produtos de baixo custo no 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ória obsoleta ou contaminada. Se seu histórico de pedidos remonta a muitos anos, os padrões de demanda antigos 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.

A demanda aumenta devido a pedidos únicos. Um único grande pedido 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 acumulando ajustes ascendentes. Várias regras em que cada uma aumenta a previsão (viés de falta de estoque, aumento de tendência, aumento sazonal) podem ser agravadas. Analise quais regras estão ativas e verifique se todas se aplicam aos mesmos produtos.

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

Sinais de previsão externos não estão sendo incorporados. Se você tiver entradas do plano (por exemplo, previsões de EDI de clientes, planos de produção do SIOP) carregadas, mas suas regras de consenso não as estiverem aplicando, 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 de previsão (linha de base). Se forem idênticos, as regras não estão funcionando.

Combinações esparsas de produto x site reduzindo o agregado. Se você prevê a granularidade de produto × site, mas muitas combinações têm demanda zero ou quase zero, o modelo produz 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 condicional de zero nas entradas do seu plano para indicar explicitamente que “nenhuma demanda é esperada” para combinações inativas.

O modelo não capturou uma tendência recente de crescimento. Os modelos estatísticos pesam 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á atrás da tendência. Isso normalmente 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 dos dados reais recentes como um piso para as 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, aumento sazonal anterior, lançamentos de novos produtos), o modelo pode estar subprevisto durante o período divergente. Verifique se o subpreconceito está concentrado em semanas ou meses específicos que diferem do padrão do ano anterior.

Sinais externos só ajudam no curto prazo. Se você tiver regras de consenso que incorporem previsões de clientes (EDI) para as primeiras semanas, a precisão será notavelmente 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 semanas externas 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á um alto erro em horizontes mais longos. 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. As previsões de EDI ou de clientes normalmente abrangem 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 nas regras. Se o WAPE for pior do que a linha de base, incorporá-lo prejudicará em vez de ajudar. Considere limitar a regra a locais ou produtos específicos em que o sinal externo seja comprovadamente melhor (por exemplo, WAPE ponderado por volume abaixo de 50%).

O sinal externo não informa zeros. Muitos sistemas EDI enviam registros apenas para produtos com pedidos ativos — eles omitem produtos com demanda zero em vez de declarar 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á nenhum registro. 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 imediata (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 hierárquica: substituição direta nas semanas 1 a 3, combinada nas semanas 4 a 6, linha de base apenas 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 ordenação 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. Frases ambíguas podem 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 nas colunas de dimensão (ID do produto, ID do site, data). Se os nomes das colunas diferirem 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 se encaixam no 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 união exigir uma correspondência exata, as datas que reconhecem o fuso horário e as que não conhecem o fuso horário não coincidirão. Verifique se as colunas de data foram convertidas para o mesmo formato antes de serem unidas.

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 a contagem de registros no sistema — se eles mostrarem zero linhas para uma entrada do plano, o arquivo pode ter falhado ao carregar.

O consenso forecast_id corresponde ao forecast_id da linha de base. 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 referenciar a coluna errada. Se sua regra diz “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 por todas as linhas. Verifique 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 geral desfará a regra específica. Certifique-se de que as descrições das regras indiquem claramente a ordem de prioridade.

Adicione uma regra de arredondamento como etapa final de consenso. Uma regra simples de “arredondar para o inteiro mais próximo” aplicada após todas as outras regras de consenso eliminará 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 arredondar para quantidades operacionais. Se seus produtos são 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 de embalagem em seu produto principal. Compartilhe seu MOQ ou dados de tamanho de 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 × local. Um limite mínimo de histórico aplicado no nível de 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 de implantar. Antes de ativar uma regra de pré-processamento, conte quantas combinações de produto × site passam pelo filtro versus seu total atual. Se mais de 20% forem excluídos, a regra provavelmente é muito agressiva. Comece com um limite tolerante e aperte gradualmente.