O telefone tocou às 2:30 da madrugada. Era o atendimento ao cliente, e a atendente parecia prestes a chorar. "Um cliente fez um pedido, o OMS mostra 40 unidades disponíveis, o separador foi até a posição e não encontrou... nada. Nem mesmo o canto de uma caixa na prateleira."
Já recebi essa ligação mais de uma vez. Todo incidente se desenrola da mesma forma: a TI diz que os logs da interface estão limpos, as operações dizem que os livros estão limpos, e os dois lados passam a reunião culpando um ao outro. A equipe do armazém leva a culpa. Vender a mais não custa só aquele pedido: penalidades dos marketplaces, queda na avaliação do vendedor, avaliações ruins. O combo completo custa muito mais do que essas 40 unidades jamais valeriam.
Depois de casos suficientes, aprendi que as divergências de estoque entre OMS e WMS sempre se resumem às mesmas cinco causas-raiz. E existe uma sequência fixa para descobrir qual é a sua. Siga-a em ordem e a maioria dos incidentes é localizada em meia hora.
Quando os números discordam, é uma de cinco coisas
Atribua a culpa corretamente antes que alguém comece a discutir. Discutir primeiro é a maneira mais cara de gastar um incidente.
Primeiro, o atraso de sincronização. A maioria das integrações OMS-WMS sincroniza por agenda, não em tempo real. Dentro da janela de sincronização, os dois sistemas devem discordar: é por design, não um bug. Um número surpreendente de "divergências" acaba sendo alguém comparando o número do OMS de cinco minutos atrás com o número do WMS de agora. Compare os carimbos de data/hora antes de comparar as quantidades.
Segundo, estoque em trânsito nunca deduzido. Pedidos alocados, separações em andamento, mercadoria preparada para expedição: o WMS já retirou essas unidades do "disponível", mas o OMS ainda as mostra como estoque em mãos. Na alta temporada, com milhares de pedidos por dia, só o volume em trânsito pode abrir uma diferença de várias centenas de unidades entre os dois sistemas.
Terceiro, devoluções recebidas mas nunca lançadas. O WMS recebeu a devolução e a guardou; a mercadoria física está de volta. Mas a mensagem que lançava essa devolução no OMS se perdeu ou falhou. O OMS ainda acha que essas unidades foram vendidas, então o disponível para promessa roda permanentemente baixo, e a diferença continua crescendo.
Quarto, ajustes de contagem cíclica nunca sincronizados. O WMS fez as contagens, lançou os ganhos e as perdas, e o ajuste nunca chegou ao OMS. Com o tempo os dois lados se afastam cada vez mais, e a deriva parece aleatória, o que torna a investigação miserável.
Quinto, mapeamento multiarmazém quebrado. O "Los Angeles DC" do OMS mapeia para dois prédios físicos no WMS, ou um novo centro de fulfillment foi criado no OMS mas nunca adicionado à tabela de mapeamento do WMS. Esta é a mais sorrateira: cada sistema é internamente consistente, e tudo só parece errado quando você os compara.
Esta é a regra prática que uso: quando cada sistema parece certo sozinho e errado só em comparação, suspeite do mapeamento ou das definições de sincronização. Quando a diferença continua crescendo com o tempo, suspeite de devoluções ou ajustes de contagem que pararam de fluir.
Um exemplo real. No ano passado, um armazém de e-commerce de artigos para casa mostrava uma diferença de duzentas a trezentas unidades toda segunda-feira de manhã, limpa o resto da semana. Trabalhamos a sequência: carimbos de data/hora, trânsito, devoluções, contagens, tudo certo. Descobrimos que o turno da noite do fim de semana tinha feito movimentações de posição no WMS usando um código de prédio antigo. A tabela de mapeamento não tinha entrada para esse código, então todo o lote de ajustes foi silenciosamente descartado a caminho do OMS. A segunda-feira de manhã mostrava a maior diferença, e as expedições normais dos dias úteis a "diluíam" gradualmente, produzindo um ciclo semanal perfeito. Quando uma discrepância tem ritmo, observe o padrão, não só os números.
Quando quebrar, siga as etapas antes de culpar
Não convoque reunião nem atribua culpa até identificar o tipo de causa-raiz. Uma pessoa, um laptop, nesta ordem.
Comece alinhando os carimbos de data/hora. Leve os dois números ao mesmo ponto no tempo antes de comparar, para descartar o ruído da janela de sincronização. Só esta etapa filtra pelo menos um terço dos falsos alarmes. Muita gente pula, queima duas horas investigando e depois descobre que estava comparando momentos diferentes.
Se a diferença sobreviver ao alinhamento de tempos, verifique o trânsito. No WMS, some o alocado-ainda-não-separado, o em-separação e o preparado-para-expedição, e concilie isso com a diferença. Se bater, você tem um problema de definições: ou a fórmula de disponível do OMS precisa deduzir o trânsito, ou as operações precisam entender que estoque em mãos não é o mesmo que vendável.
Se o trânsito não explicar, verifique as devoluções. Puxe a última semana de recebimentos de devolução do WMS e concilie linha a linha com os lançamentos de devolução do OMS. Preste atenção especial à fila de retentativas falhadas. Muitas integrações são "dispara e esquece": uma mensagem perdida fica numa fila que ninguém monitora.
Se as devoluções estiverem limpas, verifique as contagens cíclicas. Exporte os ajustes de contagem recentes do WMS e verifique se cada um tem seu registro de sincronização correspondente no OMS. Ajustes de contagem são de baixa frequência mas alto impacto; um único envio perdido pode deixar uma discrepância pendurada por meses.
Por fim, verifique o mapeamento. Coloque a lista de armazéns do OMS e a lista de prédios físicos do WMS lado a lado e percorra as entradas de mapeamento uma a uma. Prédios novos, posições temporárias de estoque avançado na alta temporada e sites de dropship de terceiros são onde os mapeamentos se perdem. Se o mapeamento estiver errado, as quatro primeiras etapas foram esforço desperdiçado: a base em si está torta.
Essas cinco etapas localizam o elo que falha em cerca de nove de cada dez casos. Só então fale de responsabilidades: o atraso de sincronização é uma decisão de arquitetura, então a TI é dona dele. Lançamentos de devolução falhados são um problema de integração, TI de novo. Contagens nunca enviadas são um problema de processo, operações. Mapeamento quebrado geralmente significa que os dois lados nunca se alinharam quando o prédio abriu, então divida essa ao meio. Minha recomendação é escrever a divisão do trabalho e guardá-la: as operações são donas da reconciliação diária, a TI das interfaces e dos jobs. Quando algo quebrar, siga as etapas em ordem, e ninguém pode reclamar primeiro.
Pare de esperar a próxima ligação das 2 da manhã
Solucionar problemas é apagar incêndio. Prevenção de incêndio são três mecanismos, nenhum caro.
Primeiro, rode um job diário de reconciliação. Compare o disponível do OMS com o disponível do WMS por SKU e alerte automaticamente ao passar de um limite. Não deixe o limite apertado demais: costumo sugerir algo como mais de 5 unidades ou 2% da quantidade vendável de um SKU, senão a fadiga de alertas mata tudo em uma semana. Envie os alertas para o chat do grupo de trabalho, não só por e-mail. Ninguém lê esses e-mails.
Segundo, envie os ajustes de contagem ao OMS em tempo real. Muitas empresas ainda os agrupam no fim do mês, o que significa que os dois sistemas ficam simplesmente errados um em relação ao outro por alguns dias todo mês. Mude para envio-ao-ajustar. Tecnicamente é mais uma chamada de API.
Terceiro, torne o trânsito visível no OMS. Deixe o atendimento ao cliente e as operações verem as quantidades em trânsito e preparadas ao lado do estoque em mãos, não um solitário número de estoque. Quando chegar a ligação de venda a mais, o atendente pode dizer se está realmente sem estoque ou só num carrinho em algum lugar, e ninguém precisa acordar ninguém às duas e meia.
Faça essas três coisas e as divergências não vão zerar, mas as ligações das 2:30 da madrugada devem cair pela metade.
Uma última pergunta para você: qual é a sua acurácia de estoque OMS-WMS agora? Antes de responder, pense em onde você procuraria esse número, com que frequência alguém o verifica e que tamanho de diferença dispara uma ação. Se não conseguir responder às três, aquela ligação às duas e meia vai tocar de novo. É só uma questão de quando.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
