No outono de 2024, assisti a uma demo de WMS para um armazém de e-commerce em Mira Loma, na Califórnia. O vendedor falou por uma hora inteira: otimização inteligente de ondas, gêmeos digitais, de tudo um pouco. O dono assentia. O gerente de TI preencheu três páginas de anotações.
Levantei a mão. «Pausa. Tem um pedido urgente de uma conta-chave que precisa sair hoje. Adicione à onda que você acabou de liberar. Ao vivo, por favor.»
O especialista da demo congelou por três segundos, começou a fuçar nos menus, clicou por aí durante dois minutos e finalmente sorriu: «Nós certamente suportamos pedidos urgentes — só não está configurado no ambiente da demo de hoje.»
Cinco segundos de silêncio. O dono fechou o caderno.
Já vi essa cena se repetir mais vezes do que consigo contar: deslumbrante nos slides, indefeso assim que aparece um cenário real de armazém. Depois de acompanhar uma dúzia de seleções de WMS ao longo dos anos, cheguei a uma lição dura: a lista de funcionalidades é o jogo do fornecedor, e todas as caixinhas já vêm marcadas. Entregue a eles seus cenários reais e faça-os se apresentar ao vivo, e esse passa a ser o seu jogo. Nove em cada dez fornecedores começam a suar no terceiro cenário.
Meu método padrão é este: uma semana antes da demo, envio ao fornecedor cinco cenários escritos a partir da nossa operação real — dados mascarados, lógica real. No dia da demo, nada de slides; tudo acontece ao vivo dentro do sistema. Não pergunto «vocês têm esta funcionalidade?». Conto os cliques do mouse, observo por quantas telas eles saltam, verifico se as exceções realmente disparam alertas. Um WMS é tocado milhares de vezes por dia. Três cliques a mais por tarefa são centenas de milhares de movimentos desperdiçados por ano.
«Coloque um pedido urgente na onda ao vivo. Agora mesmo.»
O cenário é simples: a onda está liberada, os separadores já estão andando pelos corredores com suas pistolas RF, e o atendimento ao cliente liga — um pedido de uma conta-chave precisa sair hoje, encaixe-o na onda atual.
Três coisas para observar: dá para injetar um pedido numa onda liberada; a nova tarefa chega ao coletor do separador em tempo real ou espera a próxima onda; a onda meio separada se bagunça.
A resposta clássica do fracasso: «Suportamos pedidos urgentes, mas seria preciso fechar a onda atual e reconstruí-la.» Desclassificação imediata. Num armazém de verdade não dá para simplesmente fechar uma onda — no pico, com milhares de pedidos por dia, fechar uma onda para toda a linha de separação por meia hora. Há um fracasso mais sorrateiro também: ele injeta bem o pedido, mas nada aparece na pistola do separador até um supervisor avisar todo mundo um por um pelo rádio. Isso mostra que o «tempo real» dele só existe nos slides.
O pallet misto de devoluções é onde os sistemas vão para morrer
Todo WMS fica lindo na expedição. As devoluções são o detector de mentiras. O cenário: chega um pallet misto de devoluções — algumas unidades revendáveis, outras com a embalagem amassada a caminho do descarte, e duas caixas que foram enviadas por engano e voltaram junto com a devolução.
Observe: o recebimento da devolução gera automaticamente uma tarefa de QC em uma única etapa; uma decisão de QC de «descarte» dispara o fluxo de descarte e o ajuste de estoque sem redigitar; as caixas enviadas por engano se ligam ao pedido de saída original e geram um envio de reposição.
Muitos sistemas têm um módulo de devoluções que se resume a «dá para digitar uma devolução». O QC corre no papel, os descartes são contados numa planilha. Em 2023, vi um 3PL em Fontana deixar sua área de devoluções acumular por duas semanas inteiras no pico — quando finalmente esvaziaram, a maior parte foi direto para o descarte. O dono assistia pallet após pallet sendo baixado, com a cara verde. Se a demo precisa de três telas e um campo de notas em texto livre marcado «descartar esta unidade» para processar uma devolução, isso é um fracasso — seu funcionário de devoluções nunca vai preencher esse campo de notas. Vai ficar em branco para sempre.
Movimentações de slotting e transferências entre armazéns: desmascarando o falso multiarmazém
Antes do pico, os SKUs quentes descem dos níveis superiores para a zona dourada de separação. Cenário um: gerar tarefas de movimentação para duzentas posições em lote. O sistema consegue fazer de uma vez, o estoque em trânsito aparece como em trânsito ou simplesmente congela, e as tarefas de movimentação se autoatribuem por zona de trabalho do separador.
O cenário dois é o matador: o armazém A está em falta, o armazém B tem estoque — transfira duzentas caixas de B para A. Muitos sistemas que se gabam do suporte multiarmazém tratam isso como um pedido de saída em B mais um pedido de entrada em A, com o estoque sumindo no ar por um ou dois dias no meio. O estoque contábil nunca bate com o físico. Conduzi um projeto que morreu exatamente aqui — diferenças de fim de mês tão grandes que o financeiro se recusou a assinar, e a equipe passou três dias fazendo contagens cíclicas.
Uma arquitetura genuinamente multiarmazém move isso como um único fluxo documental, com o estoque em trânsito visível de ponta a ponta. Durante a demo, apenas conte: quantas telas, quantos números de documento, e se eles se ligam entre si. Mais de dois documentos não ligados significa que você está olhando para um falso multiarmazém.
Entregue o teclado ao vilão
O último cenário é o meu favorito. Crie uma conta com permissões só de separador e tente lançar um ajuste de estoque, abrir os relatórios de custo e excluir um pedido de saída confirmado.
Três coisas para verificar: as permissões descem até o nível de botão e campo; uma ação não autorizada é bloqueada com erro ou passa em silêncio; existe um log de auditoria registrando quem tentou fazer o quê, e quando.
A evasiva clássica é «as permissões são totalmente configuráveis». Configurável e existente são duas coisas diferentes — faça-o configurar uma ao vivo, agora mesmo. Se ele não conseguir, não existe. O pior que já vi tinha exatamente dois papéis: admin e operador. O operador podia excluir pedidos, ajustar estoque e ler todos os relatórios de custo. O vendedor deu de ombros: «Empresas pequenas não precisam de tanta granularidade.» Você é uma empresa pequena hoje. E em três anos, com quatro armazéns? Migrar para fora do sistema nesse ponto custa o suficiente para fazer você chorar.
Cinco cenários depois, você terá eliminado setenta a oitenta por cento dos candidatos. Negocie preço, prazo e serviços com quem sobrou — a base já está verificada, então não tem como perder feio.
Mas, honestamente, há algo que importa mais do que qual fornecedor você escolhe, e que é constantemente ignorado: quem escreveu esses cinco cenários, em primeiro lugar?
Já vi isso vezes demais — a TI lidera a seleção, o teste cobre APIs, arquitetura e single sign-on, e nenhum ponto de dor operacional real entra nele. Chega o dia do go-live, a TI assina, e os separadores xingam nos corredores: não dá para injetar um pedido urgente, as devoluções correm no papel, as transferências correm em planilhas. Nenhuma das perguntas que a TI fez importa no chão de fábrica.
Então a pergunta que eu deixaria com você é esta: da próxima vez que sua empresa selecionar um WMS, quem escreve a prova? Porque quem escreve as perguntas decide qual sistema você acaba comprando.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
