Há um ritual estranho que tenho visto se repetir em projetos de armazéns automatizados nos últimos anos. O fornecedor do WMS e o fornecedor do WES se sentam à mesma mesa de reunião. Falam de interfaces, falam de hardware, tudo é cordial... até que alguém diz "alocação de tarefas". Então os dois lados começam a se olhar, com o pensamento legível nos olhos: esse é o seu trabalho.
Depois da reunião, o cliente sempre me puxa para o lado. "Lao Mi, quem é realmente o responsável por isso?" Eu costumo responder com uma pergunta minha: "Está no seu contrato?" Nove vezes em dez, a resposta é não. E esse silêncio é exatamente o problema. Liberação de ondas, picks urgentes, tratamento de exceções: três tarefas que ninguém quer assumir e três frentes onde os projetos de automação viram discussão.
Liberação de ondas: o WMS escreve a melodia, o WES controla o tempo
A versão de manual é limpa. O WMS agrupa os pedidos em ondas por prioridade e horários de corte das transportadoras, libera uma onda de cada vez, e o WES executa. Um lado define a estratégia, o outro faz o trabalho.
Depois chegaram os AMRs e os shuttles, e a história ficou confusa. O fornecedor do WES vai dizer que ele enxerga o status em tempo real de cada robô e o congestionamento de cada corredor, então consegue montar e liberar ondas de forma dinâmica, muito mais eficiente do que as liberações rígidas e cronometradas do WMS. A resposta do fornecedor do WMS: ondas são estratégia de pedidos, são compromissos de fulfillment, e nenhum fornecedor de equipamentos decide isso.
Eu vi essa briga de perto em 2023, num centro de fulfillment de e-commerce no Inland Empire, no sul da Califórnia: um galpão de mais de 200.000 pés quadrados, com quarenta ou cinquenta AMRs no chão. O WMS liberava uma onda a cada 20 minutos conforme os cortes das transportadoras. O WES não dava conta: os robôs ainda estavam mastigando a onda anterior quando a próxima caía. Os separadores ficavam nos corredores esperando tarefas enquanto os robôs circulavam vazios. A equipe do WMS dizia que sua lógica de ondas era sólida; a equipe do WES dizia que o ritmo de liberação era impossível. O cliente, sentado entre os dois, ouvia argumentos razoáveis dos dois lados.
Meu veredito: a estratégia de ondas pertence ao WMS — as regras de agrupamento, a lógica de prioridade, isso é gestão de pedidos e fulfillment. Mas o ritmo de liberação tem que ser compartilhado com o WES, porque só a camada de execução sabe o que os equipamentos realmente conseguem engolir. Na prática, não há um dono único aqui, só copropriedade, e ela precisa estar escrita nos dois contratos: o WMS é dono da configuração da estratégia de ondas, o WES é dono do ritmo de liberação, e o contrato da interface diz que o WMS publica as ondas enquanto o WES publica sua capacidade em tempo real de absorver trabalho. Quais campos, qual lógica — no papel.
Picks urgentes: a batata quente do armazém
Nada é mais disputado do que os picks urgentes: o atendimento ao cliente liga, uma conta-chave tem um pedido de emergência, ele precisa sair em duas horas. O WMS marca como prioridade máxima e empurra para o WES. O vendedor do WES prometeu priorização dinâmica na demo. No go-live, inserir um pedido num plano de tarefas já sequenciado significa recalcular rotas, e a eficiência de todo o chão cai. O WMS diz: "Eu marquei a prioridade, o resto é com você." O WES diz: "Você marcou, mas eu não consigo executar."
Em 2024, num site 3PL em Ohio, a alta temporada trouxe dezenas de picks urgentes por dia, quase um por hora nos piores momentos. Ao investigar, o WES não tinha nenhuma via dedicada para tarefas aceleradas. Todo pick urgente passava pela fila normal de resssequenciamento, o solver ficava cada vez mais lento, e os pedidos normais eram arrastados junto. O cliente, furioso: "Não foi isso que vocês nos venderam."
Eu resumi a solução em três condições inegociáveis: a autoridade sobre os picks urgentes está no WMS — quem pode acelerar, e quantas vezes por dia, porque tem que haver uma cota, e o que passar da cota vai para aprovação manual; acelerar sem cota é um desastre garantido, o WES vai se afogar em interrupções ilimitadas, e isso é física, não bug de software. A execução dos picks urgentes está no WES — reserve capacidade ou construa uma via dedicada para que as tarefas aceleradas não destruam a sequência global. E o SLA vai no contrato — do momento em que um pick urgente é emitido até o momento em que sua execução começa, não mais do que um número acordado de minutos. O número é negociável. Ter um número não é.
Tratamento de exceções: onde os sistemas inteligentes se fazem de bobos
Terceiro, as exceções. Um robô trava, uma etiqueta não lê, uma checagem de peso falha — a tarefa morre no meio do caminho. Quem intercepta? Quem decide: tentar de novo ou jogar para um humano? A linha do fornecedor do WMS: "Nós somos o sistema de cima; o WES deveria tratar as exceções primeiro e escalar o que não conseguir." A linha do fornecedor do WES: "Nós operamos os equipamentos; exceções de negócio — como algo errado no próprio pedido — isso é decisão do WMS."
Os dois soam razoáveis. Na prática, as exceções que nenhum lado assume simplesmente somem dentro do sistema. Num projeto, durante os primeiros três meses após o go-live, o WES acreditava ter reportado exceções que o WMS acreditava nunca ter recebido. Encontrar a causa raiz levou mais de uma semana, e era quase embaraçoso: os códigos de exceção que o WES estava enviando não existiam no dicionário do WMS, então a interface os descartava em silêncio. Uma caixa ficou num transportador por dois dias. Ninguém sabia.
Então as exceções precisam ser divididas em duas camadas. As exceções da camada de equipamentos — robôs travados, conexões perdidas, leituras que falham — pertencem ao WES, que deve tentar se autocurar primeiro: tentar de novo, rerotear, e só então escalar. As exceções da camada de negócio — pedidos cancelados, divergências de estoque — pertencem ao WMS. E entre as duas camadas deve haver uma única tabela de correspondência de códigos de exceção, assinada pelos dois fornecedores e testada linha por linha durante a integração. A maioria dos projetos não tem essa tabela. Eles testam que a interface conecta e cantam vitória. Lembre-se: uma interface conectada não é a mesma coisa que um fluxo de exceções funcionando.
As verdadeiras causas raiz — e como eliminá-las por escrito
A esta altura, as causas raiz provavelmente estão claras. Mas deixe-me nomeá-las, porque nomeá-las é o que as torna contratuais.
Comecemos pelo fato de que ninguém jamais definiu o que é um WES de verdade. Dez anos atrás, o WMS rodava tudo e os equipamentos eram burros. Depois os AMRs e os shuttles ganharam cérebro, e o WES nasceu para gerenciá-los. Mas a indústria nunca padronizou a fronteira do WES — o WES de um fornecedor é praticamente um pequeno WMS, o de outro é mal e mal um agendador de dispositivos. Na seleção, você acha que está comprando a mesma coisa de cada licitante. Não está. As demos parecem iguais; os contratos descrevem dois animais diferentes.
Depois há o problema mais profundo: os dois lados estão "otimizando", mas otimizam coisas diferentes. O WMS otimiza o fulfillment — taxa de entregas no prazo, cumprimento dos cortes. O WES otimiza a eficiência dos equipamentos — utilização dos robôs, vazão dos corredores. O fulfillment quer velocidade; os equipamentos querem suavidade. Eles estão em tensão por natureza, e as ondas, os picks urgentes e as exceções são exatamente onde esses dois objetivos colidem. Então as acusações não são um problema de atitude. As funções objetivo genuinamente discordam.
E o mais danoso: não está no contrato. O statement of work do WMS diz "O fornecedor é responsável pelo módulo de alocação de tarefas". O statement of work do WES diz a mesma frase. Fronteiras sobrepostas mais redação vaga equivalem a um convite permanente para discutir.
Então, como escrever isso no contrato? O modelo que dou aos clientes é uma tabela simples de três colunas: item, dono, coproprietário. Ela cobre pelo menos oito itens: definição da estratégia de ondas, ritmo de liberação de ondas, autoridade e cotas de picks urgentes, via de execução de picks urgentes, autocura de exceções de equipamentos, arbitragem de exceções de negócio, manutenção do dicionário de códigos de exceção e propriedade dos campos da interface. Cada item tem exatamente um dono. "Suporte" ou "assistência" não conta como atribuição.
Também insisto em algumas cláusulas duras: critérios de aceitação detalhados — a tabela de códigos de exceção testada linha por linha com taxa de aprovação de 100%, os picks urgentes indo da emissão ao início da execução em menos de cinco minutos, onde o número é negociável mas ter um não é. Responsabilidade pela manutenção do dicionário de exceções atribuída a uma pessoa nomeada, com qualquer código novo sincronizado para o outro lado em 48 horas. E uma cláusula de desempate que adicionei depois de me queimar algumas vezes e nunca mais removi: disputas de fronteira são decididas pelo cliente em 48 horas, e nenhum dos lados pode parar o trabalho enquanto discute.
De volta àquela sala de reunião. Da próxima vez que o fornecedor do WMS e o fornecedor do WES se sentarem juntos e começarem a se olhar por causa da alocação de tarefas, eu costumo interromper: parem de se olhar, abram o contrato, achem a página e a linha. Fronteiras não se resolvem discutindo em reuniões. Resolvem-se escrevendo. Escreva e os dois lados conhecem seus trabalhos; deixe vago e cada exceção, cada pick urgente vira uma nova discussão. E o custo de todas essas discussões cai, sempre, sobre o cliente.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
