Nos últimos dois anos, percorri as naves de mais de uma dúzia de armazéns que operam robôs móveis autônomos, e um padrão se repete sem parar: robôs de duas, às vezes três, marcas diferentes compartilhando o mesmo piso. Em 2024, em um campus de fulfillment de e-commerce no leste da China, os AMRs de passagem por baixo da Marca C e os AMRs estilo empilhadeira da Marca D compartilhavam um único corredor principal, cada um respondendo ao seu próprio gerente de frota. Durante o primeiro mês após a entrada em operação, dois robôs de marcas diferentes foram despachados para o mesmo endereço de armazenagem — uma colisão de despacho — mais de 30 vezes por dia. Conversando com integradores de sistemas, ouço a mesma história com frequência crescente: frotas de várias marcas eram raras antes de 2021 e se tornaram visivelmente comuns desde 2023. As causas, curiosamente, convergem muito e se agrupam em três.
Como as frotas mistas são montadas
A primeira causa são fusões e aquisições. Quando um 3PL adquire outro, o equipamento do armazém A e do armazém B acaba sob o mesmo teto, e as marcas naturalmente não combinam. A segunda é a troca de fornecedor na expansão da fase dois: o piloto rodou em uma marca premium, depois um concorrente derrubou a proposta em 20 a 30 por cento, o diretor financeiro assinou feliz, e a dor de cabeça da integração chegou meses depois. A terceira é a mais comum e a mais injusta: a compra do piloto e a compra da expansão foram feitas por decisores diferentes que nunca conversaram entre si, e quando os dois lotes de robôs chegaram, todos perceberam que falavam duas línguas diferentes.
As três apontam para a mesma conclusão: frotas mistas raramente são planejadas; elas são montadas. E como não são planejadas, a camada de programação costuma ser a última coisa em que alguém pensa — embora seja a mais difícil de acertar.
Três armadilhas, cada uma mais funda que a anterior
A primeira armadilha é o protocolo. VDA5050, o protocolo de comunicação aberto impulsionado conjuntamente pela associação da indústria automobilística alemã (VDA) e pela federação de engenharia mecânica (VDMA), foi desenhado exatamente para que AMRs de marcas diferentes pudessem ser orquestrados por um controlador mestre. Na prática, o suporte dos fornecedores é desigual: alguns implementam apenas um subconjunto básico de funções enquanto o gerenciamento de tráfego e a preempção de tarefas ainda rodam em protocolos proprietários; outros declaram suporte no papel mas retêm campos de dados essenciais na entrega, e suas atualizações de status chegam devagar demais para a programação em tempo real. O resultado é que a camada de programação neutra que tenta reger a orquestra recebe uma partitura censurada.
A segunda armadilha é a prioridade de passagem. O RCS (sistema de controle de robôs) de cada marca só conhece os próprios robôs, planeja apenas as próprias rotas e assume que tem prioridade. Em 2023 visitei um 3PL de autopeças no Meio-Oeste americano que operava 40 AMRs de passagem por baixo da Marca A ao lado de 12 AMRs empilhadeira contrabalançada da Marca B herdados de uma aquisição, todos compartilhando uma mesma interseção do corredor principal. Os dois programadores não enxergavam os veículos um do outro; a interseção travou em média 17 vezes por dia no primeiro mês, cada uma exigindo que um humano caminhasse até lá e movesse um robô, a 8 a 12 minutos por incidente. Depois que uma camada de programação neutra assumiu o controle unificado de tráfego, os travamentos caíram para um ou dois por semana. A navegação e o desvio de obstáculos dos robôs individuais nunca foram o problema. O que faltava era um guarda de trânsito.
A terceira armadilha é a mais insidiosa: os conflitos de prioridade. Uma tarefa urgente de expedição cai na fila da Marca A enquanto uma tarefa rotineira de reposição espera na fila da Marca B, e nenhum programador enxerga a carteira de tarefas do outro — urgência e rotina são enfileiradas em mundos separados. Depois há o problema dos dados: a Marca A define utilização por horas de tarefa, a Marca B por distância percorrida, então a gerência recebe dois relatórios de KPI cujos números não podem ser conciliados, e a reunião de revisão vira dois monólogos.
Trocar os robôs ou trocar o programador: as contas
Uma frota mista acaba enfrentando duas saídas: arrancar tudo para passar a uma única marca, ou adicionar uma camada de programação neutra que governa todas as marcas. Usando como modelo ilustrativo um site de porte médio com 60 robôs (números apenas indicativos; valem as cotações reais de cada projeto):
| Item de custo | Opção A: marca única | Opção B: camada de programação neutra |
|---|---|---|
| Descarte da frota antiga | Recuperação residual, cerca de 20-30% do preço original conforme estado e idade | Nenhum; continua-se usando |
| Compra de novos robôs | Recompra da frota inteira; o grande gasto | Nenhum |
| Software de programação | RCS do fornecedor, muitas vezes incluído ou licenciado à parte | Licença do programador neutro, por robô ou por site |
| Trabalho de integração | Uma integração WMS | Um adaptador de protocolo por marca |
| Parada para a virada | Virada de todo o site, grande janela de parada | Virada faseada possível |
| Alavancagem de longo prazo | Preso a um único fornecedor | Poder de negociação multimarcas preservado |
Em magnitude, a Opção A custa cerca de 3 a 5 vezes a Opção B. Mas a Opção A tem um benefício oculto: preços de manutenção de um único fornecedor, peças de reposição comuns e uma equipe de operações que só precisa dominar um sistema. O benefício oculto da Opção B é estratégico: sem aprisionamento ao fornecedor, as futuras expansões ainda podem ser licitadas de forma competitiva.
Quatro perguntas podem guiar a escolha: a frota passa de 30 robôs?; as zonas de operação se sobrepõem muito?; há pressão de fusão ou expansão nos próximos três anos?; a frota antiga está perto do fim da depreciação? Se as três primeiras respostas forem sim, uma camada de programação neutra costuma ser a melhor economia. Se a frota é pequena, as zonas são independentes e os robôs antigos seriam substituídos de qualquer forma, a dor de curto prazo supera a de longo prazo: unifique uma vez e pronto.
A leitura contrária é esta: quando projetos de frotas mistas falham, a causa raiz quase nunca são os robôs — é quem detém o poder na camada de programação. Quem possui o programador mestre aloca a prioridade de passagem, arbitra as prioridades e define o padrão de dados. Os fornecedores enrolando na abertura do protocolo parecem um problema técnico; na verdade é uma disputa de poder — uma vez que uma camada neutra assume o comando, os robôs são rebaixados a atuadores. Então, na seleção de fornecedores, não compare apenas as especificações dos robôs. Faça mais uma pergunta: no seu protocolo proprietário, os campos de controle de tráfego e de preempção de tarefas estão realmente abertos? Essa única pergunta evita metade das armadilhas.
No lado das tendências, o VDA5050 está passando de um desejável a um obrigatório nos projetos de logística automotiva europeia, e os fornecedores de programadores neutros que o suportam estão amadurecendo rápido. A pergunta aberta que vale a pena digerir: uma vez que a camada de programação se torne verdadeiramente independente — um componente padrão multimarcas — o que será commoditizado em seguida? O próprio robô seguirá, até que os AMRs compitam como as empilhadeiras hoje, só em preço e confiabilidade, com toda a inteligência concentrada na camada de programação? Ainda não há resposta, mas a direção é clara.
Por Dr. Chen, pesquisador de cadeia de suprimentos
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
