Veredito adiantado: uma queda de rede no armazém é de dois tipos. Cai o enlace entre os leitores RF e o WMS — chame isso de braço quebrado. Morre o próprio servidor do WMS — isso é parada cardíaca. Braço quebrado se resolve com o modo offline dos handhelds; parada cardíaca só se supera com tickets em papel mais conciliação depois. A separação de pedidos e o recebimento precisam ter contingência offline. Dashboards e relatórios são um risco que dá para assumir: perdido esse lance, olha-se depois; a carga sai do mesmo jeito.
Em 2021 eu estava liderando uma entrada em produção de WMS num armazém 3PL de 90.000 pés quadrados em Ontario, Califórnia: 30 handhelds Zebra TC52 no chão, mais de 4.000 pedidos de saída por dia na alta temporada, tudo movido a leituras RF. Numa tarde o ar-condicionado da sala de equipamentos quebrou, o switch central superaqueceu e reiniciou, e o WiFi apagou por 40 minutos. Cada tela de terminal acendeu com «falha de conexão» enquanto os separadores ficavam parados nos corredores sem nada para fazer. Por 40 minutos o armazém ficou efetivamente parado — não por falta de carga, mas porque ninguém sabia o que separar nem onde colocar. Depois daquele dia, a contingência offline entrou na lista de aceitação de todo projeto WMS que eu toco. Sem contingência, sem entrada em produção.
Quando a rede cai, os leitores RF conseguem continuar escaneando?
Sim — mas só se o aplicativo do handheld tiver um verdadeiro modo offline, não aquele de que a apresentação comercial fala.
Muitos fornecedores de WMS anunciam suporte offline quando o que o aplicativo móvel realmente armazena em cache é a tela de login, sem nenhum dado de tarefa guardado localmente. Não tome a demonstração pelo valor nominal. Durante a aceitação, puxe o plugue e teste: com a rede fora, você ainda consegue fazer picking, putaway e contagem cíclica por leitura, com cada scan armazenado no aparelho? Se sim, isso é modo offline.
Duas coisas precisam ser verdade para funcionar. Antes do turno começar, o sistema deve empurrar para cada terminal as tarefas da onda do dia, os dados mestres de endereços e a biblioteca de códigos de barras de itens — um aparelho Android de classe Zebra TC52 guarda dezenas de milhares de registros de tarefa sem esforço (verifique a documentação do seu fornecedor para os limites exatos). Uma vez que a rede cai, cada leitura fica com carimbo de data e hora e entra numa fila local, depois é enviada em ordem quando a conectividade volta. Faltando qualquer uma das metades, o resto é teatro.
Aqui vai uma armadilha em que caí de cabeça. Lá em Ontario, no momento em que a rede voltou, 30 terminais despejaram suas leituras enfileiradas no servidor de uma vez e derrubaram a interface de dados do WMS em timeouts: aproximadamente metade dos registros nunca foi gravada, e a outra metade foi gravada duas vezes. Resolvemos com duas configurações. Limitação de envios no lado do terminal — lotes espaçados, não uma enchente. E verificações de idempotência no lado do servidor — número de série do aparelho mais carimbo de data e hora como chave única, duplicatas descartadas na chegada. Se essas duas não estiverem na sua lista de aceitação, seu modo offline é decoração.
Retomar do ponto de interrupção é a mesma ideia aplicada às tarefas. Uma onda de picking morre no meio de um corte; quando o enlace volta, a tarefa deveria continuar a partir da linha interrompida, não baixar a onda inteira de novo. Isso significa que o progresso da tarefa é gravado localmente em tempo real e o envio carrega um marcador de «linhas concluídas». Teste explicitamente durante a aceitação: corte a rede na linha 20, termine o resto offline, restaure, e confira se o sistema honra essas 20 linhas. Se não honrar, devolva.
Se o servidor morrer de verdade, como rodar no papel sem caos?
Um servidor morto está fora do alcance do modo offline — os poucos dados em cache num terminal não aguentam um turno inteiro. É aí que os tickets em papel assumem. Mas papel feito de qualquer jeito é pior que ficar parado: uma vez que os livros viram uma bagunça, você vai passar três dias desembaraçando tudo depois da recuperação.
Três coisas precisam estar prontas antes que o desastre chegue, e as três são inegociáveis. Tickets de picking de emergência pré-impressos, guardados no armário do escritório do supervisor. Cada linha do modelo carrega um espaço para código de barras — código de barras do endereço, código de barras do item, campo de quantidade — sempre código de barras mais dígitos legíveis juntos. Por quê? Porque durante a digitação posterior, o administrativo pode escanear o papel em vez de digitar os SKU à mão: mais rápido, e com bem menos erros. Na nossa amostragem post mortem em Ontario, os tickets de SKU puramente manuscritos voltaram com uma taxa de erro de digitação de 3 a 5 vezes o nível normal (medido naquele projeto, aproximado); os tickets com código de barras saíram essencialmente limpos.
A numeração dos tickets é a segunda peça. Cada ticket de emergência precisa de um número único — algo como EMRG-data-sequência. O supervisor registra à mão quais tickets foram entregues a quem e quais voltaram. Papel sem números significa que na hora da conciliação você nunca vai saber se um ticket sumiu, e um ticket sumido é uma bagunça sem solução.
A terceira peça é a regra das duas pessoas para a digitação posterior. Depois que a rede volta, uma pessoa digita os dados do papel no WMS enquanto outra confere por amostragem cerca de dez por cento (aproximado — defina sua própria tolerância). Até a digitação posterior terminar, os endereços afetados ficam bloqueados: nenhum movimento em produção permitido. Misture transações em produção com digitação posterior e os livros nunca vão fechar.
Uma parte do plano B em papel é constantemente esquecida: o recebimento. Com o servidor fora, não chegam ASN, então a carga de entrada vai direto para uma área de staging, registrada no papel por placa do caminhão, contagem de peças e marcas, com fotos tiradas. As transações de recebimento esperam até o sistema voltar. Essa área de staging tem que estar demarcada de antemão — não saia caçando espaço no chão no meio da crise.
Uma vez que a rede volta, o que você concilia primeiro?
Rede de volta não significa negócio como de costume. Eu passo por três coisas numa ordem fixa, e a ordem importa.
Primeiro os carimbos de data e hora. Se os carimbos gravados offline batem com a hora do servidor decide a sequência do seu livro-razão de inventário. Terminais e servidores devem todos sincronizar com uma fonte NTP; uma deriva de alguns minutos e os registros offline e online se entrelaçam errado, e as diferenças de contagem resultantes vão te deixar louco. Quando aceito um projeto offline, desvio de propósito o relógio de um terminal em 10 minutos, corto a rede dele, e observo se o sistema sinaliza. Um projeto que não consegue detectar isso reprova na aceitação.
Segundo, duplicatas e perdas. Exporte o log de envio da fila offline e confira linha por linha contra a tabela de transações de inventário do WMS: alguma leitura foi gravada duas vezes (falha de idempotência)? Alguma leitura sumiu (timeout de envio)? Confira picking e putaway primeiro — são os movimentos de alta frequência; recebimento e contagem cíclica podem esperar a vez.
Por último, o fechamento do papel. Aposente os tickets de emergência um por um: tickets emitidos, tickets devolvidos, tickets digitados — os três números têm que bater antes de você dar como encerrado. Faltando um, siga o registro manuscrito do supervisor para baixo. Aquela queda de 40 minutos em Ontario levou uma tarde inteira para conciliar (medido no projeto). Quarenta minutos fora, quatro horas de conciliação — avise a direção sobre essa proporção com antecedência, ou eles vão achar que está tudo bem no momento em que as barras do WiFi voltarem.
E não reporte «recuperado» até o relatório de conciliação estar assinado. Minha regra: até essa assinatura, o status do armazém fica como «operações restritas» para o mundo externo.
Três coisas que você pode fazer esta semana
- Faça um teste de puxar o plugue. Escolha uma janela fora do pico, desligue um AP na zona de picking — ou simplesmente coloque um terminal em modo avião — e veja se o aplicativo consegue terminar uma onda offline com todos os dados intactos depois de reconectar. Em vinte minutos você vai saber se o modo offline do seu WMS é real.
- Imprima 50 modelos de tickets de picking de emergência. Faça-os no formato código de barras mais dígitos acima e tranque-os no escritório do supervisor. Na próxima queda de servidor, pelo menos você terá papel.
- Sincronize NTP em cada terminal e servidor. Entre em cada handheld, compare o relógio dele com o do servidor, e corrija qualquer deriva maior que um minuto. É o investimento de contingência mais barato que você já vai fazer.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
