Escalar a IA num pequeno armazém: escolher o segundo projeto depois de o primeiro piloto funcionar

Escolher mal o segundo projeto para escalar a IA num pequeno armazém custa mais do que um primeiro piloto falhado. Um primeiro piloto falhado custa uma experiência. Uma segunda escolha errada custa a confiança do pessoal de chão em cada novo sistema que vier a seguir. Já vi pequenos armazéns acertarem no primeiro piloto e depois ficarem gananciosos no segundo, e a equipa nunca mais acreditou noutra ferramenta. Dito sem rodeios, o segundo projeto não é um prémio. É um teste para saber se se aprendeu moderação.

Essa é a contrapartida que ninguém põe na apresentação comercial. Por um lado, o segundo projeto é a expansão mais barata que alguma vez se vai conseguir: os dados já fluem, as pessoas já conhecem a primeira ferramenta e acrescentar um departamento adjacente custa menos do que começar de novo noutro lugar. Por outro lado, é um amplificador de risco. O primeiro piloto tocou uma equipa; um segundo projeto num departamento partilhado toca toda a gente. Por isso aqui vai a minha conclusão desde já: escolhe exatamente um departamento, resolve exatamente um problema concreto e mantém-no estável durante três meses antes de falar de um terceiro. A ganância é o hábito mais caro na adoção de IA em pequenos armazéns.

Aprendi isto a ver outra pessoa pagar por isso. Em março de 2024, um pequeno armazém de peças automóveis nos arredores de Ontario, Califórnia, com pouco mais de 40 pessoas em dois turnos, fez um primeiro piloto magnífico. A IA ajudou a equipa de receção a conferir a documentação de entrega com a mercadoria física, e os erros de receção caíram de 7 por semana para 1 por semana em três meses. O proprietário, embalado por esse impulso, fez do segundo projeto uma previsão de contagem cíclica para todo o armazém: o sistema diria a cada localização o que contar e quando. Parecia um passo natural. Na prática, a contagem cíclica toca todo o edifício. Precisa de dados de localização exatos, saldos disponíveis exatos e dados mestres exatos, e se qualquer um deles falhar, a previsão sai errada. Na segunda semana após a entrada em produção, o sistema marcou existências mortas de rotação lenta como contagens prioritárias durante três dias seguidos. Dois trabalhadores do turno da noite gastaram 6 horas a contar artigos cujos registos já estavam corretos. Na terceira semana, a equipa de contagem tinha voltado discretamente a escolher as contagens pela experiência e a ignorar o sistema. O dano não foi a fatura do software. Foi a confiança. O proprietário admitiu-o depois ele próprio: a segunda escolha não era o problema mais doloroso, era a que soava mais impressionante.

Esse fracasso tornou-se a minha regra de seleção. Um segundo projeto não pode ser escolhido por instinto, nem a partir da página mais chamativa de uma demonstração de fornecedor. Tem de passar três testes rigorosos. Os dados já lá estão, gerados todos os dias sem correções introduzidas à mão? Quanto custa uma resposta errada: uma caminhada mais longa, ou uma expedição errada e uma linha parada? E o pessoal de chão quer mesmo isto: o responsável dessa equipa levantou ele próprio este problema, ou a direção está a impor uma ferramenta a uma equipa que nunca a pediu? Se algum dos três falhar, arquiva a ideia. Prefiro ver um segundo projeto pequeno e um pouco aborrecido do que um grande e impressionante.

Segundo projeto para escalar a IA num pequeno armazém: três testes rigorosos antes de escolher um departamento

Esta tabela não é um jogo de pontos. Obriga-te a dizer o custo em voz alta. A reposição funciona como segundo projeto não porque a tecnologia seja avançada, mas porque falha em segurança: uma má sugestão é visível na revisão, é corrigida e nenhuma encomenda errada é expedida por causa dela. A otimização de rotas de picking é a mesma história. Caminhar mais é um custo, não um acidente. Aqui vai o juízo contraintuitivo que a maioria dos proprietários entende ao contrário: o segundo projeto muitas vezes não deve ser o departamento mais doloroso. O departamento mais doloroso costuma ser o mais emaranhado e o mais sujo em termos de dados, e uma equipa que acabou de terminar o seu primeiro piloto ainda não tem músculo para o desembaraçar. Escolhe um departamento onde um erro seja barato e corrigível, constrói confiança aí e espera até o pessoal de chão começar a perguntar quando chega a vez do seu departamento. Só então vai atrás do problema mais difícil. A ordem importa mais do que a ambição.

A ordem de promoção para um segundo projeto de escalonamento de IA num pequeno armazém

Quanto à ordem, só confio do próximo para o distante. Próximo significa o departamento ao lado do primeiro piloto: os mesmos dados, as mesmas pessoas, o mesmo turno. Se o primeiro piloto vivia na receção, o segundo projeto deve olhar para a reposição ou para a arrumação ao lado, e não saltar diretamente para a verificação de saída ou para uma previsão para todo o edifício. Distante não significa nunca. Significa mais tarde, depois de o próximo estar estável. Em janeiro de 2025, um pequeno armazém de artigos para o lar perto de Dallas fez exatamente isto. O seu primeiro piloto apoiava a verificação de saída. O seu segundo projeto apenas separava as encomendas com exceções nesse passo: as encomendas com documentação pouco clara ou quantidades duvidosas iam para tratamento manual focado, enquanto as encomendas limpas continuavam a fluir. Em três meses, o tratamento médio de exceções caiu de 9 minutos por encomenda para 4 minutos, sem pessoal adicional e sem aumento de expedições erradas. Quando o proprietário propôs depois um terceiro departamento, o responsável da verificação assentiu primeiro. É isto que parece uma boa ordem: o pessoal de chão a puxar o próximo projeto para a frente, não a direção a empurrá-lo para baixo.

Quanto ao ritmo, a minha regra é rigorosa. Nas duas primeiras semanas após a entrada em produção, revê o registo de erros todos os dias; a partir da terceira semana, semanalmente. Aos três meses, faz uma revisão formal e pergunta apenas três coisas: este departamento poupou mesmo tempo ou reduziu erros, a equipa sentiria a sua falta se ele desaparecesse, e alguém se oporia se o desligasses amanhã? Se duas respostas forem não, não te apresses para um terceiro projeto. Corrige primeiro o segundo.

Um ponto de pessoal também é esquecido com demasiada frequência. O segundo projeto precisa de um responsável de chão, e esse responsável tem de ser o chefe do departamento ou um veterano desse departamento, não alguém que apenas gere o software. Um fornecedor pode ensinar cliques em botões. Só o chefe sabe que exceção aparece com mais frequência, que horas não podem dar-se ao luxo de um erro e que palavras a equipa vai realmente ouvir. Já vi um segundo projeto com excelente apoio técnico e sem responsável de chão: as sugestões chocavam com o plano real de turnos, a equipa da noite improvisava por conta própria e, passado algum tempo, ninguém consultava a ferramenta. Meia hora por dia no registo de erros e uma revisão semanal com o patrão chegam. Sem essa pessoa, não comeces.

Escrever a linha de paragem no calendário

Uma linha de paragem que só vive num plano de projeto não é uma linha de paragem. Já vi muitos planos dizerem «para se os resultados desiludirem», e quando esse dia chegou, ninguém quis admitir que a escolha estava errada. Por isso, antes de o segundo projeto começar, o proprietário, o chefe do departamento e o patrão devem acordar juntos três linhas: erros ou retrabalho acima do nível anterior à entrada em produção durante duas semanas seguidas, para; um turno a contornar o sistema durante cinco dias seguidos, para; manter a ferramenta viva a custar mais de 4 horas de trabalho por semana sem poupar pelo menos isso, para. Qualquer linha ativada significa duas semanas de regresso ao método antigo e depois uma decisão: corrigir ou abandonar. Parar não é falhar. Recusar parar é.

Um último conselho, dirigido ao proprietário mais entusiasmado logo após o primeiro piloto funcionar: o maior custo do segundo projeto não é a taxa do software. É a atenção que retiras da expedição enquanto todo o edifício aprende algo novo. A expedição não pode parar, e a confiança não pode ficar a descoberto. Escolhe um departamento onde um erro seja barato, mantém-no estável durante três meses e deixa o pessoal de chão pedir o seguinte. É isto que escalar realmente parece. Qual dos três testes rigorosos é que o teu segundo projeto chumba neste momento?

Por Lao Mi, Veterano da cadeia de abastecimento (20 yrs)

Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.