Conclusão primeiro: quando os operadores ignoram as recomendações de putaway do WMS, nove em cada dez vezes não é um problema de disciplina — é um problema de lógica. Digo isso em cada go-live. A maioria dos clientes não acredita em mim. A maioria acaba provando que estava errada.
Vi essa armadilha três vezes — bem, mais precisamente umas vinte vezes em mais de 30 implementações. O padrão é sempre o mesmo: o sistema recomenda a localização A, o operador coloca o palete na localização B, e o relatório de desvios mostra mais de 40% de não conformidade. O primeiro instinto do gerente de projeto é "mais treinamento, fiscalização mais rígida". O meu é: parem de culpar as pessoas e desmontem a lógica de recomendação.
Três razões. Cada uma dolorosamente real.
Razão 1: O slot recomendado é fisicamente inalcançável
Em 2021, fui chamado a um 3PL no sul da China que lidava com pequenos eletrodomésticos — cerca de 18,000 SKUs, mais de 600 putaways de paletes por dia. Suas regras de putaway pareciam ótimas no papel: classificação ABC por velocidade mais correspondência por cubagem mais lógica do mais próximo disponível. Duas semanas após o go-live, a taxa de desvio das recomendações era de 52%.
Caminhei pelo chão com um operador numa manhã e encontrei o culpado no mestre de localizações. De mais de 3,000 posições de palete, cada atributo de altura era o mesmo valor padrão — 1.6 metros, preenchido em massa durante a implementação porque ninguém mediu. Uma fileira de estanteria tinha sido adaptada com vigas mais baixas: altura livre real de 1.35 metros. Um palete de 1.5 metros fisicamente não cabe. O sistema continuava recomendando esses slots mesmo assim. Os operadores chegavam, viam que não cabia, e colocavam o palete onde coubesse.
Depois havia o problema da zona de temperatura. As regras diziam "alimentos preferem zonas ambiente-frescas", mas o mestre de localizações não tinha nenhum atributo de temperatura. Quais corredores eram as zonas frescas? Não estava marcado em lugar nenhum. Os operadores colocavam o produto de memória.
O fio comum: a lógica de recomendação depende de dados mestres que estão errados ou que nunca foram mantidos. Boa matemática sobre lixo de entrada produz lixo de saída.
Razão 2: A recomendação parece errada, então o chão para de confiar nela num relance
Em 2019, um armazém de e-commerce transfronteiriço em Shenzhen — o clássico negócio do "SKU herói de hoje é o morto de amanhã". O consultor de implementação (não eu — cheguei para consertar) configurou a classificação ABC com base no volume de saída dos três meses antes do go-live. O problema: o go-live foi em setembro; os dados eram de maio a julho. O mix de SKUs da alta temporada do Q4 não se parecia em nada com o verão.
O resultado: os verdadeiros mais vendidos ficaram classificados como itens C e recomendados aos corredores mais distantes; o morto usava o selo de item A e sentava nos slots dourados mais próximos da área de embalagem. Os operadores descobriram em três dias — siga a recomendação e você anda o dobro da distância na hora de separar. Então ignoraram o sistema coletivamente e localizaram por experiência.
A confiança leva três meses para se construir e três dias para se destruir. Uma vez que o chão decide "a recomendação é mais burra que meu instinto", essa lógica está morta. Você pode consertar as regras depois, mas ninguém lhes dará uma segunda chance.
A outra versão comum: dados de cubagem e peso ausentes. O mestre de itens não tem dimensões, então a "correspondência por cubagem" degenera em atribuição aleatória. Paletes superdimensionados são recomendados a slots pequenos, caixas pequenas a posições de palete completo. Num relance o operador sabe que é um absurdo.
Razão 3: Não há saída para as exceções, então contornar o sistema é a única forma de sobreviver
Esta é a mais insidiosa. O sistema só lida com o fluxo normal: palete intacto, etiqueta legível, slot vazio. Mas todo dia traz exceções — um palete quebrado que precisa ser reempilhado, um palete de SKUs mistos que não se encaixa nas regras de SKU único, um pedido urgente que precisa ser estagiado perto da embalagem, caixas de entrada com embalagem danificada que primeiro devem ir ao QC.
Se o sistema não oferece saída para essas — nenhuma função de "atribuir localização manualmente mais código de motivo obrigatório" — o operador tem duas opções: deixar a mercadoria ali parada esperando o sistema "resolver", ou colocá-la num lugar sensato e seguir em frente. O chão sempre escolhe a segunda. Os desvios se acumulam até as localizações contábeis e as localizações físicas divergirem por completo.
Em 2023, um armazém de alimentos no leste da China tornou obrigatórias as recomendações de putaway — a tarefa não podia ser fechada sem seguir a recomendação. Parece rígido, né? Os operadores inventaram um atalho: confirmar por escaneamento na localização recomendada, depois mover fisicamente o palete para onde queriam, sem deixar rastro no sistema. Os livros pareciam perfeitos. O chão era um caos. A variância de contagem cíclica chegou a 8%. Vi essa armadilha três vezes, e toda vez a configuração "obrigatória" era a culpada.
Checklist da noite do go-live: não ligue as recomendações até que estes quatro passem
- Verifique fisicamente os dados mestres de localização por amostragem. Amostre aleatoriamente 30 localizações: meça altura e profundidade livres com fita, verifique atributos de capacidade de peso e zona de temperatura. Um erro significa uma reauditoria completa. Nunca confie em valores padrão importados em massa.
- Cobertura de cubagem e peso dos itens. Comprimento, largura, altura, peso — se a cobertura estiver abaixo de 90%, esqueça recomendações inteligentes e localize por categoria de produto do jeito honesto.
- Recalcule o ABC com os três meses de dados mais recentes, e escreva no SOP: recalcular mensalmente, a cada duas semanas durante a alta temporada. A janela de dados deve coincidir com o ritmo do negócio.
- Saída para exceções mais um relatório de desvios. O sistema deve suportar "localização manual mais código de motivo", e até o dia dois após o go-live, o gerente de projeto deve conseguir tirar um relatório de variância de "localização recomendada vs. localização real". Três códigos de motivo bastam: localização indisponível, recomendação irrazoável, caso de exceção.
Mais dois pontos de falha que repito em cada go-live: primeiro, o ABC calculado uma vez no go-live e nunca mais tocado por três anos — isso é o mesmo que não ter nenhum. Segundo, os testes só cobrem o fluxo normal; ninguém testa "e se o slot recomendado estiver ocupado" ou "e se o palete exceder a altura". O chão vai te ensinar essa lição no dia um.
Aqui estão as contas. Um armazém que faz 500 tarefas de putaway por dia: cada contorno custa ao operador mais ou menos um minuto extra achando um slot e outro minuto corrigindo a localização no sistema. Isso é umas 16 horas por dia — duas pessoas em tempo integral sem fazer nada além de compensar o sistema. E isso exclui o percurso extra de separação por estoque mal localizado e as variâncias de contagem cíclica. Consertar a lógica de recomendação costuma custar uma ou duas semanas de limpeza de dados mestres. As contas nem se comparam.
E uma visão contraintuitiva para fechar: 100% de conformidade com as recomendações não é necessariamente uma boa notícia. Uma taxa de desvio saudável fica em torno de 5–15%, com um código de motivo em cada desvio. Abaixo de 5%, comece a se preocupar que o chão esteja confirmando por escaneamento e depois fazendo o que quer. Acima de 30%, a lógica já está morta — pare de treinar gente e conserte a lógica.
A reunião de turno de amanhã de manhã: dedique 15 minutos para perguntar ao seu líder de putaway uma pergunta — quantas recomendações falharam ontem, e o que aconteceu em cada caso? Pergunte uma semana seguida e você saberá exatamente com qual das três razões está lidando. Diagnostique primeiro, depois aja. Não comece com "mais treinamento".
Por Lin Xiao, consultora de implementação de WMS
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
