Seu piloto funcionou. Sua implantação morreu. Nove em cada dez vezes, resume-se a três coisas.
Já vi esse filme vezes demais. Em 2023, ajudei um 3PL nos arredores de Plainfield, Indiana, a pilotar um otimizador de rotas de picking com IA em uma instalação de 180,000 pés quadrados. Seis semanas depois, os ganhos de eficiência fizeram o cliente perguntar quando poderíamos entrar em operação em todos os lugares. Dez armazéns, disseram. Chegamos ao armazém número dois em Ohio antes de tudo travar. Os separadores de lá ignoraram por completo as sugestões de rota do sistema. O terceiro site nunca começou, e a cláusula de implantação do contrato ficou ali juntando poeira. Esse projeto me ensinou algo que hoje digo a todo cliente: um piloto prova que a tecnologia pode funcionar. Uma implantação testa se ela pode sobreviver ao prédio de outra pessoa.
Causa da morte um: seus dados do piloto foram criados em estufa
Dados de piloto nunca são naturais. Pense no seu piloto. Os engenheiros do fornecedor acamparam no site por semanas? Alguém rotulou à mão cada pedido de exceção? Disseram aos separadores, explicitamente, para seguir o sistema e não improvisar? As pessoas se comportam de forma diferente quando sabem que estão sendo observadas. Os dados saíram limpos porque toda a operação estava se comportando da melhor forma, como uma casa modelo.
Foram esses dados mimados que o seu modelo aprendeu. Depois, o armazém número dois não recebe nenhum desses cuidados. Scans são pulados, motivos de devolução são escolhidos aleatoriamente, mudanças de slotting ficam dois dias sem registro. Mesmo modelo, outro jantar. E a degradação é lenta: o primeiro mês parece bom, no terceiro mês as recomendações começam a desviar, os operadores deixam de confiar nelas, e a desconfiança piora os dados. Uma espiral da morte que ninguém percebe até ser tarde demais.
Então o primeiro passo de qualquer implantação é uma auditoria da linha de base de dados em cada novo site. Mande alguém morar lá por duas a quatro semanas e não mude nada. Apenas observe: conformidade de scans, integridade dos dados mestres, quão rápido as exceções são processadas. Se um site não consegue igualar a qualidade de dados que o seu armazém piloto tinha, corrija os dados primeiro e programe o go-live para depois. Esse tempo e dinheiro não podem ser pulados. Pule-os e você pagará dez vezes mais.
Causa da morte dois: o modelo sente saudade de casa no armazém número dois
Dois prédios ambos chamados de "armazém" podem ser espécies diferentes por dentro. Nosso piloto em Plainfield fazia picking de caixa fechada com um perfil de SKU concentrado e rotas de deslocamento fixas. O site de Ohio lidava com e-commerce de pequenos pacotes com uma ordem de magnitude a mais de SKUs e uma lógica de ondas completamente diferente. Tudo que o modelo havia "aprendido" era quase inútil lá.
As diferenças se acumulam em três camadas. Uma é o mix de produtos e pedidos: caixa fechada versus fracionados, B2B versus venda direta ao consumidor — as premissas do modelo mudam por baixo dele. Segunda, o processo: dois sites podem chamar de "picking" a mesma coisa enquanto um separa para um put wall e reconfere, e o outro separa direto para totes. Mude os passos e as ações sugeridas pelo modelo deixam de corresponder à realidade. Terceira, e a mais traiçoeira: as versões de sistema. Dois sites com versões de WMS separadas por dois releases podem definir o mesmo evento de "picking concluído" com semântica de campos e lógica de timestamps diferentes. Conecte a interface e os dados chegam desalinhados.
Minha regra agora: antes de qualquer site novo entrar em produção, preencha um registro de variações contra o site piloto — perfil de produto, tipos de pedido, passos-chave do processo, versões de sistema e campos de interface, item por item. Onde as lacunas forem grandes, corrija o processo e alinhe as definições de dados antes de o modelo aparecer. Nunca espere que o modelo se adapte à sua bagunça. Ele não pode. E uma regra dura: congele as atualizações de versão do WMS e da interface durante a implantação. A falha mais injusta que já vi foi uma equipe de TI que atualizou o WMS no meio da implantação; uma definição de campo mudou e os modelos de três sites em produção quebraram ao mesmo tempo. Um congelamento não significa nunca atualizar — significa que cada atualização passa primeiro por uma regressão do modelo em testes.
Cada novo site também recebe um período de sombra. O sistema faz recomendações, mas não assume as decisões; os operadores trabalham como sempre fizeram. Duas a quatro semanas de comparação: onde as sugestões do sistema divergem das escolhas dos veteranos, e se a lacuna é um problema de dados ou prova de que o modelo genuinamente não entende esse prédio. Os dados de sombra são a única base legítima para a decisão de virada completa. Nunca decida no instinto.
Causa da morte três: ninguém quer usar, e a conta não fecha
Durante o piloto, os executivos o patrocinavam, o fornecedor estava no site, e os operadores estavam curiosos. Durante a implantação? O gerente do novo site pensa "esse é o projeto da matriz, não o meu bônus". Os operadores pensam "isso me faz escanear duas vezes, por que eu faria isso?". Quando a sugestão da IA conflita com o instinto de um veterano de vinte anos, o veterano vence, porque ninguém está do lado da IA.
A estrutura organizacional precisa chegar junto com a tecnologia. Cada site de implantação precisa de um dono de negócio nomeado — e digo negócio, não TI. As metas trimestrais dessa pessoa devem incluir "implantação de IA em produção e performando nos níveis medidos no piloto". As pessoas lutam pelo que está no plano de bônus. Essa é a natureza humana; não lute contra a natureza humana.
E não desmonte a equipe do piloto. O erro mais comum que vejo: o piloto dá certo, a equipe do fornecedor vai embora, a equipe interna do projeto se dissolve, e cada site fica sozinho para descobrir a replicação. Em vez disso, converta a equipe do piloto em um esquadrão de replicação carregando o registro de variações, o padrão de linha de base de dados e o manual de operação em sombra, trabalhando site por site. Suporte total para os três primeiros sites, só revisão a partir do quarto, mãos fora depois do sétimo. Esse ritmo não pode ser apressado.
A matemática do ROI também precisa estar fechada com o financeiro antes da implantação, não depois. O ROI do piloto geralmente é "matemática ideal": economia de mão de obra contada, custos de implementação ignorados, retrabalho por recomendações falsas ignorado, mão de obra duplicada durante o modo sombra ignorada. Quando o financeiro soma tudo de volta durante a implantação, os números parecem magros e o projeto é questionado. Melhor fazer você mesmo a conta honesta com antecedência: implementação, remediação de dados, o custo de erros de picking por más recomendações — tudo incluído, amortizado por site. Um ROI magro, mas real e replicável, supera um ROI gordo e irreplicável todas as vezes. Use os números medidos do seu piloto, não o deck do fornecedor, quando se sentar com o financeiro.
Antes de copiar esse piloto para o próximo prédio, percorra este checklist: a linha de base de dados do site foi atingida, o registro de variações foi preenchido, as versões de sistema estão congeladas, o período de sombra está agendado, o dono de negócio foi nomeado com a implantação em suas metas, o esquadrão de replicação continua intacto, a metodologia de ROI foi acordada com o financeiro? Se você não consegue responder sim às sete, não instale nada ainda. Vencer um piloto uma vez é sorte. Repetir essa vitória dez vezes é a verdadeira habilidade.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
