A demo foi impecável. Quarenta e cinco minutos, e cada clique caía como uma nota de piano. Os pedidos fluíam do ERP, as ondas saíam no horário, os operadores seguiam as instruções dos terminais RF, as etiquetas imprimiam, as carretas carregavam. O engenheiro de vendas até sorriu durante a parte do "alguma pergunta?". Meu VP de Operações virou-se para mim depois e disse: "É esse. Vamos assinar."
Seis meses depois, na primeira semana da entrada em produção, eu estava no mesmo armazém vendo um supervisor rabiscar separações numa prancheta porque os terminais RF estavam na fila há quarenta minutos. Uma carreta perdeu seu horário porque a liberação de ondas silenciosamente derrubou 300 pedidos. As devoluções da temporada de fim de ano estavam há dois dias num canto porque ninguém tinha decidido quem era dono daquele fluxo. Aquele armazém era uma instalação 3PL de 380,000 pés quadrados no Inland Empire, cerca de 4,000 pedidos por dia no pico, e o contrato de WMS era de $210,000 por ano. A demo não tinha nada a ver com isso.
Assisti a pelo menos uma dúzia de demos de WMS em vinte anos gerenciando armazéns e selecionando sistemas. Todas pareciam ótimas. Eis a verdade inconveniente: demos são feitas para parecer ótimas. O conjunto de dados da demo é limpo — todos os SKUs têm as dimensões certas, os códigos de barras leem, o estoque bate. O fluxo segue o caminho feliz — uma separação, uma caixa, uma transportadora, nada danificado, ninguém separa a menos, ninguém devolve nada. E o engenheiro de vendas ensaiou aqueles cliques uma centena de vezes. Ele sabe exatamente quais botões apertar e quais telas pular. Você não está vendo o software. Está vendo uma performance.
Uma prova de conceito de verdade é o oposto de uma performance. É adversarial. Você entrega sua bagunça ao fornecedor e pede para ele sobreviver.
É assim que faço agora, depois de me queimar.
Primeiro, a POC roda com os seus dados, não com os deles. Exporte duas semanas dos seus pedidos reais — todos, incluindo os feios — e um cadastro de SKUs real, incluindo os itens com dimensões erradas e códigos de barras ausentes, porque eles existem em todos os armazéns que já gerenciei. Se um fornecedor reluta em carregar seus dados e insiste em usar seu conjunto de dados de sandbox, esse é seu primeiro sinal de alerta. Um WMS que só funciona com dados limpos é um WMS que não funciona.
Segundo, escreva os critérios de aceitação antes da POC começar, e pondere-os para os ramos anormais. O fluxo normal vai passar. São sempre as exceções que matam: separações curtas, recebimentos danificados, liberações de onda que precisam ser reconstruídas no meio do turno, embarques fracionados, devoluções sem RMA. Insisto em roteirizar pelo menos 60% dos testes de aceitação em torno de exceções. Peça à equipe do fornecedor para rodar uma liberação de onda com corte da transportadora em dez minutos enquanto dois pedidos ficam curtos. Observe o que acontece. Isso é uma terça-feira num armazém de verdade.
Terceiro, limite o tempo. De duas a quatro semanas, parada dura. Mais que isso e vira uma implementação fantasma em que o fornecedor embute consultores, constrói gambiarras sob medida e chama de "POC bem-sucedida". Você quer uma fatia representativa, não um universo paralelo. Se quatro semanas não bastam para o fornecedor mostrar os fluxos principais com seus dados, o produto é pesado demais para você. Saia fora.
Quarto, coloque a superfície de integração no escopo — sem exceções. A demo de WMS sempre mostra uma caixinha arrumada de "integração ERP" no slide de arquitetura. Na realidade, é aí que as implementações morrem. Sua POC tem que incluir o aperto de mão de verdade: ordens de compra descendo do ERP, embarques e estoque subindo de volta, e etiquetas de transportadora imprimindo na estação de embalagem com cotação real de fretes. Vi uma entrada em produção atrasada em onze semanas porque o cadastro de itens do ERP usava uma convenção de UOM diferente da do WMS e ninguém mapeou até a terceira semana de testes. Isso custou à empresa cerca de $60,000 só em consultoria estendida. Teste as costuras cedo, porque é aí que vazam.
Quinto, exija que o fornecedor exponha a documentação da API e os logs de erro. Isso surpreende as pessoas. A demo mostra a interface. A equipe de operações vive nos logs. Durante a POC, algo vai falhar — um trabalho de impressão de etiquetas, uma chamada de API para a transportadora, uma sincronização com o ERP. Peça para ver como você descobre o que aconteceu. Existe um log de erros legível? Sua pessoa de TI consegue chamar a API sem ligar para o suporte do fornecedor? Um fornecedor que trata sua documentação de API como um complemento premium está dizendo exatamente como será o suporte depois da entrada em produção. Acredite.
Agora, as três armadilhas. Vi essas explodirem entradas em produção mais do que qualquer outra coisa.
Armadilha um: os fluxos anormais nunca foram testados. Essa é a grande. A doca de recebimento recebe um embarque com 200 caixas danificadas pela chuva. Um operador derruba uma caixa e o produto fica invendável. Um pedido é cancelado depois que a onda já foi liberada. Em todo postmortem de que participei, a lista de "isso a gente nunca testou" tem três páginas, e é tudo exceção. Demos nunca mostram. A maioria das POCs também pula, porque é constrangedor de roteirizar. Roteirize mesmo assim. Seu armazém roda em exceções; sua POC também deveria.
Armadilha dois: o volume de migração de dados nunca foi testado sob estresse. A POC geralmente carrega algumas centenas de SKUs e roda bem. Aí chega a entrada em produção com 18,000 SKUs, seis meses de pedidos abertos e três anos de perfis de clientes para migrar, e os jobs de sincronização levam nove horas em vez de nove minutos. Vi uma instalação perder todo o seu programa de embarques de uma segunda-feira de outubro — o início da alta temporada — porque o upload inicial de estoque travou as tabelas e os pedidos não podiam ser liberados. Rode um teste de carga em volume total durante a POC. Leva um fim de semana e poupa você do pior tipo de surpresa.
Armadilha três: ninguém ligou para os clientes de referência. Fornecedores entregam uma lista de referências brilhantes, e metade das equipes de compra nunca liga. Ligue para todos. Mas não pergunte "vocês estão satisfeitos com o sistema?". Faça perguntas específicas: "Quantos dos seus fluxos de exceção vocês tiveram que customizar?", "O que quebrou no primeiro mês da entrada em produção?", "Quanto tempo um ticket de suporte leva para ter uma resposta de verdade?". Uma ligação de referência me salvou de um erro de sete dígitos em 2019 — o gerente do armazém me disse que a entrada em produção dele tinha atrasado cinco meses e que precisaram de dois consultores do fornecedor em tempo integral no local por um ano. A equipe de vendas do fornecedor tinha descrito esse mesmo cliente como uma "implementação tranquila".
Então aqui vai a versão curta — o checklist de aceitação que entrego aos fornecedores antes de uma POC começar:
Rode com meus pedidos reais e meus SKUs reais, dados bagunçados incluídos. Cubra as exceções, não só o caminho feliz — separações curtas, danos, ondas reconstruídas, devoluções. Termine em quatro semanas ou menos. Inclua no escopo o aperto de mão com o ERP, as etiquetas de transportadora e a documentação da API. Mostre-me um log de erros legível quando algo falhar. Teste de carga em volume total. E me deixe ligar para suas referências com perguntas específicas.
Se um fornecedor resiste a qualquer um desses pontos, isso não é um problema de negociação. É informação.
O que eu faria amanhã
Se você está avaliando fornecedores de WMS agora, faça uma coisa esta semana: pegue as três exceções mais feias do mês passado — o recebimento danificado pela chuva, a onda reconstruída, a devolução que ninguém sabia processar — e escreva-as como roteiros de teste antes da próxima chamada com um fornecedor. Entregue-as ao engenheiro de vendas e diga: "Me mostre isso na POC." O olhar no rosto dele dirá tudo sobre o produto. E não custará nada, que é o seguro mais barato de todo esse negócio.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
