Sejamos francos: um piloto de IA bem-sucedido e um rollout escalável são dois animais diferentes. Já vi esse filme vezes demais. O armazém nº 1 roda um piloto lindo — precisão de picking em alta, taxa de erros em baixa, aplausos na revisão trimestral. Depois o armazém nº 2 trava. O armazém nº 3? Ninguém nem menciona.
O fato é este, e ele corta para os dois lados. Pilotos vencem com pessoas e investimento: seu melhor prédio, sua equipe mais forte, os engenheiros do fornecedor no local, tudo concentrado num só lugar. Claro que funciona. Escalar vence com algo completamente diferente: padrões, disciplina e um respeito saudável pelo fato de que não existem dois armazéns iguais. Copiar o manual do piloto tal e qual é pedir problema.
Em 2023, um 3PL em Ontario, Califórnia — fulfillment de e-commerce, seis prédios na rede — me procurou. O prédio nº 1 havia pilotado visão computacional para verificação de picking. Três meses depois, a taxa de envios errados tinha caído para quase zero, e o cliente estava encantado. O CEO acenou com a mão: rolem para todo lugar. O prédio nº 2, em Dallas, entrou no ar e desmoronou na hora. Mesmo SKU, mas os dados mestres — nomes de itens, regras de códigos de barras — não batiam em nada com os da Califórnia. O modelo reconhecia imagens sem problema, mas no momento em que tentava confrontar com o SKU do sistema, nada conferia. A precisão caiu de 99% no piloto para pouco mais de 90%. A turma do chão protestou. O projeto ficou congelado por dois meses de retrabalho, e só a limpeza de dados custou mais do que o piloto inteiro.
Essa é a barreira número um.
Barreira nº 1: os dados do piloto não viajam até o prédio nº 2
IA come dados, não slides. Os dados do piloto costumam ser "renovados" antes do início do projeto: o fornecedor e a equipe de TI higienizam os dados mestres, conectam as interfaces, ajeitam os fluxos de exceção. Mas o prédio nº 2? O WMS dele pode estar duas versões para trás. As regras de códigos de barras foram definidas há uma década. As convenções de nomenclatura de SKU variam de prédio para prédio, e os códigos de motivo de devolução nunca foram padronizados.
Já vi empresas demais concluírem "resolvemos o problema de dados" durante o piloto. Não — vocês resolveram o problema de dados do prédio nº 1. Cada prédio carrega um passivo histórico diferente, e cada um impõe um teto ao que os dados podem entregar. Replicar significa refazer em cada site o trabalho de governança de dados do piloto — e esse item nunca esteve no orçamento do piloto.
A solução: torne isso regra de ferro no kickoff do piloto. Toda "limpeza de dados pontual" feita para o piloto precisa ser capturada como script reutilizável e SOP — e provada no prédio nº 2 antes de o piloto contar como sucesso.
Barreira nº 2: o dream team do piloto não se transfere
Atrás de todo piloto bem-sucedido há um dream team: o melhor consultor de implementação do fornecedor, o líder de TI mais afiado da matriz, o gerente de site mais cooperativo da rede. Esses três grupos não vão seguir você por cada prédio.
O problema mais difícil é o pessoal do chão. Sites piloto são dotados de voluntários — energia alta, engajamento alto. No prédio nº 2, a primeira reação a "a IA está chegando" é "isso vai me substituir?". Em 2022 vi um DC de vestuário onde os pickers do piloto ajudavam ativamente a IA a corrigir seus erros, enquanto os pickers do segundo site colavam deliberadamente as etiquetas tortas. Não foi uma falha tecnológica. Foi uma falha de confiança. A equipe do projeto passou um trimestre inteiro em treinamento e incentivos antes de a adoção se recuperar.
Isso tem dois lados, e ambos importam: a tecnologia é a parte fácil de copiar. As pessoas são a parte difícil. O sucesso do piloto cria a ilusão de que a parte difícil era técnica. Nunca foi.
A solução: dê às "pessoas" uma linha própria no orçamento do rollout. Cada prédio novo recebe pelo menos um veterano do piloto no local por três meses — treinamento, incentivos, tratamento de exceções, tudo. Economize aqui e você estará plantando minas.
Barreira nº 3: escalar para vários sites reescreve o ROI
Essa é a que dói. O ROI do piloto costuma estar distorcido: fornecedores dão desconto ou cortesia no POC para ganhar o contrato corporativo e ainda colocam engenheiros no local. O piloto roda no seu melhor prédio, então os ganhos parecem enormes. Depois chegam os orçamentos reais: licenças de software por prédio, taxas de integração por site, suporte cobrado por dia.
Uma vez expliquei a um cliente a conta real de um projeto de verificação de picking por visão computacional. O piloto e o rollout tinham estruturas de custo completamente diferentes:
| Item de custo | Piloto (1 prédio) | Réplica (prédios nº 2–3, por prédio) |
|---|---|---|
| Licenças de software | Com desconto ou grátis | Preço cheio, por prédio |
| Integração de sistemas | Uma vez, a TI da matriz absorve | Por prédio; sistemas legados custam extra |
| Governança de dados | Feita informalmente pela equipe do projeto | Refeita em cada prédio |
| Treinamento e gestão de mudança | A equipe do piloto cobre por fora | Frente de trabalho separada, orçamento separado |
| Retornos | Melhor prédio, maior base | Prédios medianos, ganhos marginais decrescentes |
Vê o padrão? Os custos sobem, os retornos minguam. Um piloto com um ROI lindo não diz nada sobre o ROI do rollout. Muitos projetos morrem no prédio nº 2 — não porque a tecnologia falhou, mas porque o CFO olhou para a conta da réplica e não assinou.
E aqui vai a opinião contrária: quanto mais bem-sucedido o piloto, mais perigoso o scale-up. O sucesso faz todo mundo subestimar a dificuldade de replicar. Orçamentos são aprovados de qualquer jeito; obstáculos são imaginados para longe. A jogada de veterano é o oposto — no dia do kickoff do piloto, exija o orçamento para o prédio nº 2, e orce contra seu prédio mais difícil, não contra o melhor. Um piloto que sobrevive ao prédio mais difícil é um sucesso de verdade.
Cinco perguntas antes de replicar
Na prática, antes de dar sinal verde ao rollout, responda a estas cinco perguntas. Não consegue responder uma? Corrija isso primeiro.
- As interfaces de dados e os padrões de dados mestres do prédio nº 2 podem reutilizar diretamente a configuração do piloto? Se não, qual o tamanho da limpeza?
- A equipe do piloto pode ceder pelo menos uma pessoa para ficar alocada no prédio nº 2 por três meses?
- Você tem em mãos o orçamento multisite do fornecedor — por prédio, ou em pacote?
- O gerente do site do prédio nº 2 realmente quer este projeto, ou foi designado pela matriz?
- O ROI do rollout foi recalculado com os números reais do prédio nº 2, ou apenas copiado do piloto?
Acerte as cinco e suas chances disparam dramaticamente. Erre uma, e você sabe exatamente por onde começar.
Um último conselho: da próxima vez que rodar um piloto de IA, faça ao fornecedor uma pergunta antes de assinar — "Posso ver agora mesmo o orçamento para o armazém nº 2?". Pergunte, e você vai descobrir que o final de muitas histórias de "sucesso de piloto" foi escrito muito antes de o piloto começar.
Por Lao Mi, veterano de supply chain (20 anos)
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
