Eram 21h40 de uma noite de terça-feira quando o gerente de operações me ligou. Ele tinha aquela calma plana que as pessoas adotam quando já fizeram as contas e não gostaram do resultado. "Vendemos 300 unidades de um SKU hoje à noite", disse ele. "O WMS mostra zero em estoque. O OMS ainda diz que temos 40."
Nenhum sistema estava quebrado. A integração entre o sistema de gestão de pedidos dele e o sistema de gestão de armazém funcionava exatamente como projetada. O problema era o próprio projeto: ninguém tinha perguntado o que "funcionar" realmente significava para os números de estoque que fluem de volta para cima. Essa lacuna de 40 unidades era o atraso de sincronização, e quando alguém percebeu, os pedidos com venda excedente já estavam no sistema.
Já vi esse filme vezes demais para saber o roteiro de cor. A direção OMS→WMS — os pedidos descendo — recebe toda a atenção durante a implementação. O caminho de volta, o estoque subindo, é construído como um pensamento tardio. E é ali que o dinheiro vaza.
O número na sua tela do OMS é história, não transmissão ao vivo
Vamos seguir o fluxo real de dados. Os pedidos chegam de todos os canais de venda, pousam no OMS para roteamento e alocação, e depois descem para o WMS para separação, embalagem e envio. No sentido contrário, o WMS precisa reportar ao OMS os recebimentos, as armazenagens, as separações e os ajustes de contagem, que por sua vez envia as quantidades disponíveis para venda para cada canal. Esse trecho de volta é onde mora o atraso, e ele vem de 3 lugares.
O primeiro é a frequência de sincronização. Muitas integrações ainda funcionam por agendamento — a cada 15 minutos, a cada meia hora, às vezes a cada hora. Isso significa que 200 unidades separadas no WMS às 20h05 só aparecem no OMS na próxima execução agendada. Durante o pico de tráfego noturno, essa janela é exatamente quando a venda excedente acontece. Migrar para envios orientados a eventos (um recebimento registrado, um ajuste de contagem aprovado, e a atualização dispara imediatamente) fecha a lacuna, mas multiplica as chamadas de API, e você bate de frente com limites de taxa e custos de infraestrutura. Isso é uma decisão de negócio, não um quebra-cabeça técnico.
O segundo são as sincronizações falhas que ninguém percebe. Um trabalho em lote falha, tenta de novo 3 vezes e morre em silêncio. Em instalações demais não há nenhum alerta em caso de falha — a operação descobre na manhã seguinte que as atualizações de estoque pararam de fluir 6 horas atrás. Já vi um armazém onde um lote de ajustes de contagem cíclica foi registrado corretamente no WMS, mas o trabalho de sincronização para cima travou, e os canais venderam contra números com 2 dias de idade por 48 horas.
O terceiro é o atraso humano. A carga está na doca, mas o recebimento ainda não confirmou no sistema. Uma divergência de contagem está sentada na fila de um supervisor esperando aprovação. A latência do sistema se mede em minutos; a latência humana se mede em horas ou dias. Metade das reclamações de "precisão de sincronização" que investiguei acabou sendo problema de processo disfarçado de problema de sistemas.
Um pedido com venda excedente custa mais do que o cancelamento
É por isso que trato o atraso como um problema de dinheiro, não como um chamado de TI. A venda excedente dispara uma cadeia, e cada elo custa.
Primeiro vem o cancelamento. Cancelamentos iniciados pelo vendedor são um dos sinais mais feios que você pode enviar a um marketplace. A política da Amazon mantém os cancelamentos pré-envio iniciados pelo vendedor abaixo de 2,5% em uma janela de 7 dias, e a taxa de defeitos de pedido abaixo de 1% em uma janela de 60 dias — cruze essas linhas e você corre o risco de restrições aos seus privilégios de venda. Algumas dezenas de pedidos com venda excedente numa noite de pico podem estourar a taxa de cancelamento sozinhas, e a saúde da conta não se recupera da noite para o dia.
Depois vem a carga do atendimento ao cliente: reembolsos, desculpas, avaliações negativas. O custo de mão de obra de atender um pedido com venda excedente geralmente supera a margem que aquele pedido teria gerado. E o custo mais silencioso é o da gambiarra — alguns vendedores correm para conseguir o item em outro lugar e o enviam atrasado com o dobro do custo de frete, essencialmente pagando a mais para ganhar uma avaliação ruim.
Você não pode eliminar o atraso, mas pode reduzi-lo e se proteger contra ele
Meu veredito de antemão: o atraso de sincronização entre o OMS e o WMS nunca pode ser zero. 2 sistemas, saltos de rede, limites de taxa de API — sempre haverá segundos ou minutos de defasagem. O objetivo é reduzir o atraso a algo que o negócio consiga absorver, e então construir barreiras para o resto.
Reduzi-lo se resume a 3 decisões de configuração. Primeiro, torne os eventos críticos em tempo real: uma armazenagem concluída e um ajuste de contagem aprovado devem empurrar para o OMS imediatamente. Os pedidos descendo podem continuar em lote; o estoque subindo deve ser orientado a eventos onde o orçamento permitir. Segundo, sincronize o campo certo. O WMS deve enviar o disponível para venda — o estoque disponível menos o alocado menos as retenções de qualidade — não o bruto disponível. Já auditei integrações que passavam quantidades brutas disponíveis e deixavam o OMS tratá-las como vendáveis. Isso é superestimação embutida. Terceiro, mantenha o mapeamento multiarmazém limpo. Quando um SKU está em 3 prédios, a consolidação do OMS deve excluir o estoque em trânsito e o estoque congelado, ou o número "disponível" é ficção.
O seguro tem 2 partes. Uma: reserve um colchão de segurança nos SKUs quentes. Se a quantidade real disponível é 500, deixe o OMS listar 460 e guarde 40 como amortecedor contra a janela de atraso. Você está trocando um pouco de velocidade de venda por proteção — dimensione o colchão em torno da pior taxa histórica de vendas por hora do SKU multiplicada pelo seu intervalo de sincronização, para cobrir pelo menos um ciclo completo de atraso. Dois: rode uma conciliação diária com alertas de variação. 1 vez por dia, durante a calmaria noturna, compare instantâneos completos de estoque dos dois sistemas e alerte quando a variação cruzar um limiar. A conciliação não é teatro contábil — é assim que você descobre um trabalho de sincronização morto às 6h da manhã em vez de ficar sabendo por clientes furiosos ao meio-dia.
Quando explodir à meia-noite, verifique estas 3 coisas
Pedidos com venda excedente na fila? Não comece o jogo das culpas. Trabalhe esta sequência e você geralmente terá a causa raiz em meia hora.
Verifique primeiro o log de transações do WMS. Procure naquele SKU, em torno da janela do incidente, grandes separações, ajustes de contagem ou recebimentos registrados. Um número surpreendente de "vendas excedentes misteriosas" acaba sendo um ajuste de contagem cíclica registrado na direção errada, ou uma devolução recebida 2 vezes.
Depois verifique o log do trabalho de sincronização. Olhe o carimbo de data e hora do último instantâneo de estoque que o OMS tem daquele SKU. Se o instantâneo tem 3 horas enquanto os pedidos continuaram fluindo 1 hora atrás, o atraso é seu culpado. Preste atenção especial às novas tentativas falhas — foi um timeout, um limite de taxa ou uma incompatibilidade de formato de dados?
Por fim, verifique a lógica de alocação do OMS. Confirme que a quantidade disponível usada no momento da alocação incluía o colchão de segurança, e que pedidos já alocados mas ainda não liberados não foram contados 2 vezes. Bugs de alocação e atrasos de sincronização adoram aparecer juntos, e verificar apenas um lado não pega a combinação.
Depois de encontrá-lo, escreva o incidente nas suas regras de conciliação — da próxima vez, o alerta deve disparar antes do atendimento ao cliente.
A primeira tarefa de amanhã: descubra se a sincronização de estoque do seu OMS funciona por agendamento ou envia em tempo real, e anote o intervalo. Esse número é seu tempo de reação à venda excedente.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
