Fazendo o AS/RS e o WMS conversarem: apertos de mão do WCS, mensagens de tarefa e tratamento de exceções na prática

Sejamos francos: nove em cada dez projetos de AS/RS não falham nos transelevadores nem nas tolerâncias do racking — falham na camada do meio: o WCS. O equipamento está comprado, o WMS já existe, mas os dois não falam a mesma língua, então é preciso um tradutor no meio. E se esse tradutor for ruim, quanto mais rápido o AS/RS roda, mais rápido o caos se espalha. Há dois lados nessa história. Um é a integração técnica: fazer as mensagens fluírem. O outro é quem manda quando algo dá errado — e esse é o lado que realmente te mata.

Minha conclusão antecipada: o WMS é o cérebro, o WCS é o cerebelo, o AS/RS são as mãos e os pés. Integração não é «conectar» — é as três camadas concordarem sobre o que significam «a verdade do estoque» e «o status da tarefa». Se elas discordarem, um fluxo de mensagens perfeito é só uma bomba-relógio.

Como o AS/RS e o WMS realmente «conversam»: a divisão em três camadas

Primeiro, vamos deixar clara a divisão de trabalho:

A ida e volta: o WMS emite uma tarefa — ID da tarefa, ID do pallet (ou LPN), estações de origem e destino, prioridade. O WCS a enfileira e a atribui ao equipamento. Quando o equipamento termina, o WCS responde: sucesso, falha, código de motivo. Três detalhes causam a maioria dos problemas: primeiro, em caso de timeout, exatamente um lado é dono da nova tentativa — não os dois, não nenhum. Segundo, o mesmo ID de tarefa precisa ser idempotente — se a rede engasgar e a mensagem sair duas vezes, o transelevador não pode executá-la duas vezes. Terceiro, o estoque contábil do WMS e o estoque físico do WCS precisam usar as mesmas definições — um pallet que o WMS chama de «em estoque» precisa ser realmente localizável pelo WCS. Esses três pontos vão por escrito antes de começarem os testes de integração.

Há uma mina enterrada ainda na fase de seleção: quem é dono da verdade do estoque? O WMS diz «eu sou os livros, os livros mandam». O WCS diz «eu tenho a mercadoria física, a mercadoria manda». A briga mais comum é pelo status «em trânsito» — um pallet já retirado do rack e andando pelo transportador. O WCS o considera «fora do armazenamento»; o WMS continua considerando «em estoque e alocável». Aí chega um pedido urgente, o WMS aloca esse pallet para outra tarefa, o transelevador vai até a estação e pega ar. Se essa definição não for fechada antes do go-live, vocês vão discutir sobre ela todos os dias. Minha posição é simples: a realidade física vence. O «em estoque e alocável» do WMS precisa excluir a quantidade em trânsito do WCS. Escrito no contrato de interface e fim da discussão.

Vi projetos demais onde os testes de integração só cobrem o caminho feliz: tarefa emitida, equipamento executa, confirmação OK, todo mundo aplaude. E aí a primeira semana em produção começa a dar lições.

Os três desastres clássicos que já vi vezes demais

Desastre um: o WCS cai e o WMS continua emitindo tarefas. Durante a integração pré-pico de temporada numa instalação, o servidor do WCS reiniciou no meio da madrugada por cerca de dez minutos. O WMS nunca percebeu e continuou emitindo centenas de tarefas. Quando o WCS voltou, o backlog inundou o equipamento de uma vez e a sequência foi destruída — pedidos urgentes enterrados atrás de reposições de rotina. Levou um turno de dia inteiro para desembaraçar a fila de tarefas. A autópsia encontrou a causa raiz: o intervalo de heartbeat estava configurado tão longo que um reinício completo passava despercebido.

Desastre dois: definições de conciliação de estoque em guerra. Os livros do WMS mostravam um pallet na Zona A do AS/RS; o WCS mostrava que ele havia sido baixado de forma anormal para a área manual uma semana antes, e a mensagem de retorno se perdeu numa flutuação de rede. Então o sistema dizia «em estoque» e o equipamento dizia «não», e a tarefa de separação esperava na estação à toa. Pior: esse tipo de descompasso entre livros e físico não se persegue com contagens cíclicas manuais — o throughput diário de pallets de um AS/RS levaria um mês de trabalho manual para contar. Acabaram conciliando pallet a pallet, snapshots físicos do WCS contra livros do WMS, até que cada pallet perdido fosse encontrado.

Desastre três: confirmações de exceção que ninguém atende. Um transelevador reporta «falha de separação». O WCS o converte num código de erro genérico e joga no WMS. O programa de interface do WMS não reconhece o código e o descarta. A tarefa não é nem sucesso nem falha — fica simplesmente pendurada. O operador olha para a tela esperando uma mercadoria que nunca chega, liga para o TI, e o TI diz que o sistema mostra «emitida». Três partes se encarando. A causa raiz era quase cômica: a tabela de códigos de erro tinha sido definida pelo integrador de qualquer jeito, e o lado do WMS nunca a mapeou.

Uma opinião contrária ao senso comum: quanto mais automatizado você está, mais depende do seu plano de degradação. As pessoas acham que AS/RS é dormir tranquilo. É o contrário — o maior risco de um AS/RS não é o equipamento quebrado, é o sistema acreditando que o equipamento não está quebrado. Um transelevador quebrado se vê; uma mensagem perdida, não.

Mais um detalhe que a maioria perde: a prioridade das tarefas. O «pedido urgente primeiro» do WMS vira simples fura-fila quando traduzido na camada WCS — as tarefas em andamento são interrompidas o tempo todo, as taxas de deslocamento em vazio dos transelevadores disparam. O pedido urgente sai mais rápido, o throughput total piora. A estratégia de prioridade precisa ser desenhada nas duas camadas juntas: o WMS define a prioridade de negócio, o WCS define o agrupamento de execução, cada um cuidando do seu. Todo projeto em que o WMS comanda o equipamento diretamente termina em bagunça.

Para manter o AS/RS e o WMS conversando: quatro regras de ferro

Primeira, o contrato de interface antes de tudo. Antes dos testes de integração, alinhem a máquina de estados da tarefa: emitida, executando, bem-sucedida, falhada, em espera por exceção — cinco estados, nem um a menos. Quem pode fazer cada transição, quanto timeout conta como falha — por escrito. O dono da nova tentativa pertence a exatamente um lado. As chaves de idempotência precisam atravessar toda a cadeia. As tabelas de códigos de erro precisam ser mapeadas linha a linha nos dois lados — um código tipo «erro geral» não pode existir.

Segunda, o plano de degradação. O que acontece quando o WCS cai? O WMS precisa poder pausar a emissão imediatamente, e as tarefas em andamento precisam ser exportáveis como lista para tratamento manual. Degradação não é «esperar o TI consertar» — é um procedimento de comutação que você já ensaiou de verdade. Um plano nunca ensaiado não é um plano. Meus critérios de aceitação para clientes sempre incluem uma linha: desconectem o WCS por dez minutos; depois da recuperação, tarefas e estoque precisam conciliar. Se não conciliarem, o pagamento final fica retido.

Terceira, a conciliação. A cada turno, o WMS e o WCS conciliam: estoque contábil contra posições físicas. As diferenças nunca são corrigidas editando os livros à mão — passam pelo processo de exceção: descobrir para onde o pallet foi, descobrir onde a mensagem se perdeu, e então ajustar. Os livros podem estar errados, mas errados com rastro. Editar à mão dá alívio por um momento; o armazém inteiro chora na hora da conciliação.

Quarta, o checklist de integração. Testes de estresse de mensagens, simulados de queda de rede, cobertura total de testes de cada código de erro — nada opcional. Especialmente o simulado de queda: desplugar o cabo de rede entre o WCS e o WMS por dez minutos e conferir se tarefas e estoque continuam conciliando depois da recuperação. Se sim, o projeto está genuinamente conectado. Tantos projetos morrem no «estava tudo bem durante a integração» — claro que a rede estava bem durante a integração; você nunca viu como é «não estar bem».

Para quem está escolhendo fornecedor agora, três perguntas ao integrador antes de assinar: uma, quando o WCS cai, o WMS consegue pausar a emissão automaticamente, e a lista de tarefas em andamento pode ser exportada com um clique? Duas, a tabela de códigos de erro está mapeada linha a linha no WMS, ou há códigos vagos que ninguém assume? Três, a conciliação contábil-física por turno roda automaticamente ou depende de alguém lembrar? Se não conseguirem responder uma das três, a implementação vai custar mais — não talvez, com certeza.

Da próxima vez que um integrador disser «as interfaces estão todas conectadas», faça uma pergunta: o WCS perde rede por dez minutos — o estoque de vocês continua conciliando?

Por Lao Mi, veterano da cadeia de suprimentos (20 anos)

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