Quando o WMS e o ERP divergem: falhas de interface, diferenças de estoque e quem é o dono do número

Conclusão primeiro: quando o estoque do WMS e do ERP diverge, a causa geralmente não é que um sistema calculou errado. É que os dois sistemas definem a mesma coisa de forma diferente. Uma interface quebrada é apenas o tipo de falha mais visível. Com mais frequência, o mapeamento de lote, unidade ou status está desalinhado, de modo que os livros diferem em um lançamento enquanto o estoque físico nunca se moveu. No trabalho de integração WMS-ERP para armazéns, a triagem tem uma ordem rigorosa: verifique primeiro se a interface está fluindo, depois verifique se os mapeamentos estão corretos, e só então fale sobre quem é o dono da diferença. Inverter essa ordem pode fazer você passar um mês corrigindo o lugar errado.

Já vi esse problema três vezes. O caso mais recente foi um cliente de bens de consumo na terceira semana após o go-live. O financeiro dizia que o ERP mostrava um produto de papel com falta de mais de duas mil unidades. O armazém dizia que o estoque físico estava todo lá, e uma contagem cíclica concordou com eles. Cada lado tinha certeza de que o outro estava errado, e a equipe do projeto quase reconstruiu a interface do zero. A causa real era quase embaraçosa: o ERP gerenciava o estoque por caixa, o WMS o gerenciava por peça, e a interface enviava quantidades em caixas que o lado receptor registrava como peças. Com vinte e quatro peças por caixa, um único pedido criava uma diferença de vinte e três unidades. Nada estava quebrado. Faltava uma linha na tabela de mapeamento de unidades.

Falhas de interface na integração WMS-ERP: quatro tipos, em ordem

Quando uma interface falha, não reinicie o serviço primeiro. Uma reinicialização só corrige uma interrupção temporária. Não corrige um erro de configuração. Eu classifico as falhas de interface em quatro tipos e as elimino uma por uma. Primeiro, a mensagem nunca saiu: o documento de saída fica em uma fila pendente no WMS, muitas vezes porque seu status está errado, por exemplo um pedido não aprovado que a interface nunca vai buscar. Segundo, saiu mas nunca chegou: a fila do middleware está congestionada, ou um certificado expirou, e a profundidade da fila mais os logs de erro deixam isso óbvio. Terceiro, chegou mas foi rejeitada: um campo ausente, ou um código que não existe nos dados mestres do outro sistema, faz a mensagem ser devolvida. Quarto, e o mais perigoso: chegou e foi lançada, mas lançada errado, por exemplo um erro de conversão de unidade ou uma divergência de código de armazém, de modo que os livros se afastam silenciosamente e o problema explode dias depois.

Em toda checklist da noite de go-live, insisto em três itens: um alerta para acúmulo na fila da interface, um botão de nova tentativa com histórico de tentativas para documentos com falha, e um responsável diário pela limpeza de documentos que o outro lado rejeitou. Uma interface sem esses três itens está operando desprotegida. Já trabalhei com um cliente cuja interface quebrava toda noite na mesma hora, porque o envio programado colidia com a janela de manutenção noturna do outro sistema. Mover a janela de envio resolveu. Verifique os horários e os logs antes de suspeitar do código.

Tabelas de mapeamento para a integração WMS-ERP: lote, unidade e status

Uma vez que a interface flui e os livros ainda divergem, verifique três tabelas de mapeamento. A primeira é o mapeamento de unidades: caixa, palete, peça, embalagem interna, qual sistema é dono da unidade base, onde vive a conversão e se alguma categoria de produto é uma exceção. A segunda é o mapeamento de lotes: o número de lote do ERP é a mesma coisa que o número de lote do WMS? Algumas empresas usam a data de produção como lote no ERP enquanto o WMS usa um número de lote de recebimento, e os dois parecem iguais sem coincidir. A terceira é o mapeamento de status: pendente de inspeção, em trânsito, congelado, danificado, a que corresponde cada status de estoque do WMS no ERP, o estoque danificado conta como disponível, o estoque congelado fica nos livros?

A falha mais típica que já vi foi um status "pendente de inspeção" ausente. Mercadorias aguardando inspeção de qualidade ficavam em status pendente no WMS, mas o ERP as contava como estoque disponível, de modo que as vendas aceitavam pedidos com base nesse número e depois não conseguiam expedir. A correção não foi complicada: imprimir a tabela de mapeamento de status, fazer os donos de negócio dos dois lados assinarem linha por linha, colocar o estoque pendente, congelado e danificado cada um em seu próprio grupo, e deixar as vendas verem apenas o status disponível. Faça a tabela ser assinada antes do go-live, não apenas acordada verbalmente.

A reconciliação precisa de uma tabela de divergências fixa, e não de uma nova extração de dados toda vez que algo dá errado. A tabela precisa de pelo menos quatro colunas: produto, quantidade do WMS, quantidade do ERP e motivo da divergência. A coluna de motivo admite apenas cinco valores: interface não chegada, conversão de unidade, mapeamento de status, diferença de lote ou diferença física. Qualquer linha marcada como "outro" volta para nova investigação. Rode essa tabela por um mês e você verá que os motivos de divergência se concentram bastante, geralmente uma ou duas categorias se repetindo. Essa disciplina é o que faz a reconciliação da integração WMS-ERP para armazéns se sustentar ao longo do tempo. Corrija esses um ou dois pontos e a divergência total cai drasticamente.

Quem é o dono do número: defina a regra antes da discussão

Quando os livros divergem, a parte mais cara raramente é corrigir o número. É os dois lados se culparem. O armazém diz que o sistema enviou errado, a TI diz que o negócio digitou errado, o financeiro diz que nenhum lado é confiável. Portanto, a responsabilidade deve ser definida antes de um problema aparecer, por escrito nos documentos de go-live, e não discutida depois do fato.

A divisão que usamos é simples. Problemas de transmissão de interface pertencem à TI, julgados pelos logs de transmissão: se o log mostra que foi enviado e o outro lado não recebeu, a camada intermediária é a dona. Problemas de regras de mapeamento pertencem à equipe do projeto, julgados pela tabela de mapeamento assinada: o que a tabela diz é como se conta. Problemas físicos pertencem ao armazém, julgados pelos resultados de contagem: se a contagem e o WMS divergem, verifique primeiro o estoque físico. Problemas de digitação pertencem a quem digitou o documento, julgados pelo valor original do documento, com qualquer alteração deixando rastro. Uma vez que a regra existe, uma divergência é primeiro classificada e encaminhada ao seu dono, sem gastar metade de uma reunião decidindo de quem foi a culpa.

Aqui está um julgamento contraintuitivo: quanto menor a divergência, mais seriamente você deve levá-la. Uma diferença de duas mil unidades é investigada por todos. Uma diferença de três ou cinco unidades é dispensada com um ajuste manual, porque parece próxima o suficiente. Mas pequenas divergências são muitas vezes o sinal precoce de um erro de mapeamento. Três unidades hoje podem ser três mil no mês que vem. Nossa regra é que toda divergência entra na tabela com uma categoria de motivo, mesmo que se revele um escaneamento extra durante uma contagem. Pequenas divergências não registradas significam que, quando uma grande chega, você nem sabe por onde começar a procurar.

Checklist de go-live para integração WMS-ERP em armazéns

Para concluir, aqui está uma checklist que você pode usar diretamente. Na noite do go-live, marque cada item: a tabela de mapeamento de unidades cobre as categorias de exceção, a tabela de mapeamento de status está assinada pelos donos dos dois lados, a regra do número de lote é a mesma coisa nos dois sistemas, a interface tem alertas de falha e um mecanismo de nova tentativa, a tabela de divergências roda automaticamente todos os dias, o motivo da divergência está limitado a essas cinco categorias, e o documento de responsabilidade foi enviado às três partes? Sete itens, todos aprovados, então faça o go-live. Faltando mesmo um, o custo de corrigi-lo após o go-live é várias vezes o que custa agora.

A verdade direta é esta: livros de WMS e ERP que divergem quase nunca são um problema de tecnologia. São um problema de definições que a gestão nunca fechou. Escreva as definições, faça com que sejam assinadas e reconcilie todos os dias. Isso faz mais do que substituir um sistema jamais fará. Já vi esse problema três vezes, e as causas foram diferentes a cada vez, mas a solução foi a mesma: primeiro a triagem, segundo a atribuição de responsabilidade, e por último a correção do sistema.

Por Lin Xiao, Consultor de Implementação de WMS

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