Configurando uma frota de distribuição urbana com telemetria e roteirização
O primeiro passo que a maioria das pessoas erra não é a escolha do software de roteirização, mas sim a coleta dos dados de viagem. Sem dados reais de rodagem, qualquer modelo de engenharia de logística e transporte que você montar vai girar em torno de suposições, e as suposições sempre encarecem o resultado final.Antes de qualquer coisa, você precisa instalar sensores ou usar módulos CAN bus nos veículos. Eu comecei usando OBD2 dongles genéricos por baixo do painel, conectando via API REST do fabricante. Em três meses, abandonei porque a taxa de perda de dados em túneis e subsolos era de cerca de 18 por cento. Troquei por terminais GPS industriais com memória interna e upload em burst quando a conexão volta. O custo por unidade subiu de R$ 120 para R$ 480, mas a qualidade dos dados me salvou de refazer o trabalho duas vezes. A coleta gera um volume bruto de registros: latitude, longitude, velocidade, ignição ligada/desligada, tempo ocioso, frenagens bruscas. A partir desses logs brutos, o processo de engenharia se divide em quatro etapas que costumam levar entre quatro e seis semanas para rodar completo, dependendo da escala da frota.
Engenharia de logística e transporte na prática: do dado ao plano
A primeira etapa é a limpeza e validação. Você filtra pontos GPS inválidos, removes velocidades Fisicamente impossíveis acima de 180 km/h em área urbana, e reconcilia horários de ignição com janelas de entrega do ERP. Na minha experiência, cerca de 7 por cento dos registros precisam de correção manual. Não adianta tentar automatizar tudo aqui; um script mal calibrado pode apagar uma parada real e transformar sua rota em algo irreconhecível. A segunda etapa é a estimação de tempos de viagem por trecho. Aqui entra a parte que poucos fazem direito. A maioria dos materiais ensina a usar a distância em linha reta multiplicada por uma velocidade média. Isso funciona para estimativas grosseiras de longa distância, mas para distribuição urbana você precisa de uma matriz origem-destino calibrada com dados reais por período do dia. Eu construí uma matriz com 345 pares de points de entrega usando dados de duas estações completas, divididos em fatias de 30 minutos entre 6h e 22h. O resultado foi uma precisão de ETA dentro de mais ou menos 4 minutos para 82 por cento das corridas, contra 22 minutos de erro médio do método ingênuo.
A terceira etapa é a modelagem propriamente dita. Você escolhe o problema: Vehicle Routing Problem com Janelas de Tempo, ou uma variação com capcidade, ou ainda com múltiplos depósitos. O solver que eu uso rotineiramente é o OR-Tools do Google, comConstraint Programming para as janelas e Local Search para a otimização. Em frotas de até 50 veículos e 400 paradas, o tempo de resolução gira em torno de 3 a 8 minutos em um processador de escritório comum. Para frotas maiores, o tempo explode e você precisa fragmentar o problema por zona geográfica antes de rodar. A quarta etapa é a implementação no operacional. O plano gerado precisa ser convertido em instruções para o motorista, preferencialmente via app mobile, com backup offline. Aí aparece o primeiro ponto cego que quase ninguém avisa: o motorista nunca segue a rota otimizada à risca. Trânsito, clientes que não estão no endereço cadastrado, carregamento mal feito no caminhão. Por isso a roteirização precisa ser recálculada em tempo real ou, no mínimo, a cada hora. O custo dessa recorrência é alto em infraestrutura de nuvem, então eu recomendo um meio-termo: recalcular apenas os trechos afetados por mudanças significativas, mantendo o resto fixo.
Um problema específico que eu enfrentei recentemente envolveu um cliente com 28 veículos e entregas de medicamentos refrigerados. O congelador de uma das unidades tinha um sensor defeituoso que reportava temperatura estável enquanto o compressor desligava intermitentemente. O modelo de logística considerava apenas o tempo de trânsito e a capacidade de carga, mas não havia integrado a variável de cadeia fria como restrição. A solução foi adicionar um campo de tempo máximo fora da faixa de temperatura permitida por tipo de produto, e configurar um alerta quando o acumulador de tempo fora da faixa ultrapassasse 12 minutos. Isso mudou a estrutura da rota em 14 por cento dos dias, porque algumas paradas precisavam ser servidas primeiro para reduzir o tempo de exposição, mesmo que aumentasse levemente a quilometragem total.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Pitfalls comuns que começam pequenos e viram desastre
O erro mais frequente que eu vejo gente cometer é confiar na velocidade média do GPS sem considerar o efeito da topografia. Em cidades com muitos morros, como Belo Horizonte ou Porto Alegre, a velocidade média de subida pode ser metade da velocidade em nivelado. Se seu modelo não separa esses trechos, a estimativa de tempo cai pela metade na prática e o cliente espera a entrega e não recebe. Outro erro Crasso é otimizar apenas o custo de combustível e ignorar o custo trabalhista. Um veículo que roda 8 horas com carga parcial pode parecer mais barato por quilômetro, mas se ele precisar de um motorista adicional ou horas extras, o custo real salta. Em meus cálculos, o custo trabalhista corresponde a cerca de 55 a 70 por cento do custo operacional total em frotas urbanas. Modelos que ignoram essa variável produzem resultados visualmente bonitos no papel que quebram na folha de pagamento.
Ainda há o problema da volatilidade da demanda. Se você programa rotas para um dia normal e acontece um pico de pedidos, o sistema não tem flexibilidade. A solução mais barata que eu encontrei foi manter uma reserva de capacidade de 15 por cento em cada rota, tratada como folga estratégica e não como desperdício. Isso evitou contratatacao emergencial de Motoristas terceirizados em 90 por cento dos dias de pico que monitorei.
Limitações reais da abordagem
O método descrito acima não funciona bem quando a rede de entregas tem menos de 15 paradas diárias por veículo. Nesse cenário, o overhead de coleta de dados, limpeza, estimação de matriz e resolução do solver consome mais tempo e dinheiro do que o ganho em otimização. Para frotas pequenas, vale mais a pena investir em treinamento de motorista e padronização de carregamento do que em infraestrutura de engenharia de logística e transporte avançada. Também não funciona com alta variabilidade não modelável. Se os tempos de descarga dependem inteiramente do estado emocional do recebedor, nada de software vai resolver. Nesses casos, a única intervenção viável é contractual: acordos de tempo máximo de descarga com penalidades, ou a presença de cargadores próprios no ponto de entrega. A engenharia entra depois, para ajustar o que o comportamento humano já não pode mudar.
Por fim, a dependência de dados históricos é uma armadilha. Se seu cliente launching um novo bairro ou uma nova linha de produtos, não haverá dados históricos suficientes para calibrar a matriz. A solução é rodar uma fase de coleta piloto de pelo menos 14 dias antes de confiar no modelo, ou usar dados de bairros similares como proxy temporário, com a ressalva explícita de que a precisão será menor até que dados reais se acumulem. O link para baixar o template do spreadsheets de estimação de tempos de viagem e o script Python de exemplo do OR-Tools que eu uso como ponto de partida está disponível no repositório público do projeto. Os dados sensíveis de cada cliente ficam em servidores próprios, mas o esqueleto do código é aberto e documentado linha por linha. Quem quiser testar em sua própria frota pequena pode adaptar o arquivo de entrada de paradas e rodar localmente sem pagar licença de solver.
