Direto ao ponto: quando os estoques de OMS e WMS não batem, quase nunca é um bug do sistema. Essa divergência de estoque entre OMS e WMS mora em um de cinco lugares. Verifique os cinco antes de começar a questionar suas escolhas de vida. Já fiz mais de 30 go-lives e vi exatamente esse buraco três vezes: em todas, o cliente culpou primeiro o software, e em todas a causa raiz acabou sendo processo ou configuração.

Por que esses dois sistemas discordam com tanta frequência? Porque não estão contando a mesma coisa. O OMS conta o "estoque vendável": o que você pode prometer a um cliente. O WMS conta o "estoque físico": o que está realmente parado num endereço. Um gerencia compromissos de venda, o outro gerencia a realidade física, e entre eles ficam os pedidos, as mercadorias em trânsito, as devoluções e as conversões de unidade. Qualquer desalinhamento nessa cadeia divide os números.

Aqui estão os cinco checkpoints, na ordem em que eu os investigo. Cada um vem com "como verificar" e "como corrigir". Siga os passos.

Categoria 1: tempo — atraso de sincronização e trânsito nunca registrado

Checkpoint 1: atraso de sincronização. Na maioria dos projetos, a sincronização de dados entre OMS e WMS não é em tempo real: é uma tarefa agendada, normalmente a cada 15 minutos, 30 minutos ou até uma hora. Durante um pico de vendas, o WMS já expediu 200 unidades enquanto o OMS ainda espera a próxima execução da sincronização. Claro que os números não batem.

Como verificar: escolha um pedido que acabou de ser expedido. Compare o carimbo de hora da alteração de estoque no OMS com o carimbo de hora da confirmação de expedição no WMS. Se a diferença for igual ao seu intervalo de sincronização, aí está o culpado.

Como corrigir: no curto prazo, encurte o intervalo de sincronização (durante períodos de pico costumo recomendar menos de cinco minutos). No longo prazo, envie em tempo real eventos críticos como confirmações de expedição e recebimentos em vez de depender de trabalhos em lote. Nota: intervalos mais curtos aumentam a carga do sistema; valide primeiro com o time de TI.

Checkpoint 2: o trânsito nunca foi deduzido. A mercadoria foi separada, carregada e foi embora, mas o OMS nunca atualizou o status em trânsito, ou a confirmação de expedição do WMS atrasou um passo. O estoque cai numa terra de ninguém que nenhum dos dois sistemas reivindica. Vi esse buraco três vezes, e ele sempre explode na noite anterior a uma grande venda.

Como verificar: no WMS, extraia os documentos "alocado mas não expedido" e "expedido mas não confirmado" e procure atrasos acumulados. Depois examine a lógica de disponível para prometer do OMS para a mesma janela: se o trânsito é deduzido ficará óbvio.

Como corrigir: trave a etapa de confirmação de expedição do WMS. Assim que o caminhão sair escaneado, a confirmação tem que acontecer no mesmo dia: o "fazemos amanhã" está banido. Do lado do OMS, a fórmula de disponível para prometer deve deduzir explicitamente o trânsito, escrita no documento de requisitos, não combinada de boca.

Categoria 2: processo — devoluções nunca guardadas e conversões de unidade

Checkpoint 3: devoluções nunca guardadas. No ano passado, um cliente de vestuário mostrava 2,000 unidades de um SKU popular no OMS na noite anterior a uma grande venda, enquanto o WMS mostrava zero. O marketing quase tirou a página do produto do ar. A causa raiz: as mercadorias devolvidas estavam paradas há três dias na área de recebimento, sem tocar no controle de qualidade, ainda "pendentes" no WMS, enquanto o OMS já tinha devolvido as quantidades devolvidas ao estoque vendável. Um caso clássico de divergência de estoque entre OMS e WMS.

Operário de armazém escaneando um palete com um PDA na frente das estruturas

Como verificar: extraia o relatório "pendências na área de recebimento" no WMS e veja quantas devoluções estão acumuladas. Depois verifique quando o OMS devolve as devoluções ao estoque: se o OMS restaura a quantidade vendável no momento em que o cliente despacha a devolução, a definição está errada.

Como corrigir: as devoluções precisam completar o fluxo inteiro de "receber, inspecionar, guardar". O OMS só pode restaurar o estoque vendável depois que o WMS confirmar a guarda. Qualquer atraso na área de recebimento acima de 24 horas dispara um alerta: escreva essa regra no SOP.

Checkpoint 4: conversão de unidade. O mais bobo e o mais comum. O OMS vende em "caixas", o WMS acompanha em "unidades": 12 unidades por caixa. Se o fator de conversão estiver errado, o estoque sai fora por uma ordem de grandeza. Vi um projeto inflar o estoque inteiro doze vezes na primeira semana de go-live porque o fator estava configurado em 1.

Como verificar: escolha qualquer SKU, verifique a unidade de estoque no OMS e no WMS, depois verifique o fator de conversão na interface. Alinhe os três: o erro salta aos olhos.

Como corrigir: audite os fatores de conversão de cada SKU uma vez, por completo. Para itens novos, torne "unidade de venda, unidade de estoque, fator de conversão" um trio obrigatório no cadastro do item: se faltar um, o item não é criado.

Categoria 3: configuração — mapeamento errado de múltiplos armazéns, e a verdadeira divergência de estoque entre OMS e WMS

Checkpoint 5: mapeamento errado de armazéns. O "CD Leste da China" no OMS pode ser dois prédios físicos no WMS: "Xangai WH-1" mais "Xangai WH-2". Se você mapear um deles errado, o número do OMS nunca vai conciliar com o WMS. Este é o que mais dói, porque os dois sistemas estão individualmente corretos.

Como verificar: liste cada armazém lógico no OMS e os armazéns físicos correspondentes no WMS, e verifique um por um. Qualquer armazém novo, fundido ou renomeado: verifique primeiro a tabela de mapeamento.

Como corrigir: mantenha a tabela de mapeamento de armazéns separadamente. Qualquer armazém novo, fundido ou renomeado precisa atualizar a tabela de mapeamento antes do go-live. Revise a tabela de mapeamento mensalmente.

A verdade contraintuitiva: os dois lados estão "certos": o que está errado é a própria definição de conciliação. Muitas investigações terminam aqui: o OMS está certo, o WMS está certo, mas os dois sistemas definem "estoque" de forma diferente. O disponível para prometer é igual ao estoque físico menos o alocado menos o em trânsito menos as retenções de qualidade menos o estoque de segurança: os dois lados precisam usar a mesma fórmula. Se as definições não se alinham, você vai conciliar dez mil vezes e nunca vai bater. Unifique a fórmula antes de conciliar qualquer coisa.

Checklist da noite de go-live: prevenindo a próxima divergência de estoque entre OMS e WMS

Toda noite de go-live, faço o cliente percorrer esta lista e assinar antes de qualquer um dormir:

  1. Intervalo da tarefa de sincronização e alertas de monitoramento: configurados?
  2. Prazos de confirmação de expedição e guarda de devoluções: escritos no SOP?
  3. Fatores de conversão de unidade de todos os SKUs: auditados?
  4. Tabela de mapeamento de armazéns: a última versão?
  5. Fórmula de disponível para prometer: idêntica dos dois lados?

Com os cinco marcados, as chances de uma divergência de estoque entre OMS e WMS caem ao mínimo. E um sexto item: mantenha no local uma pessoa que entenda tanto o negócio quanto os sistemas. Quando algo quebra, ache primeiro a pessoa: não reinicie primeiro o servidor.

Por Lin Xiao, consultor de implantação de WMS

Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.