Roteirização que respeita a cidade
Otimização de rota é fácil de errar em centro urbano. Como modelamos restrição de horário, peso, zona azul e ZMRC sem virar quebra-cabeça.
A primeira versão do nosso roteirizador minimizava distância. Era ótimo no campo aberto e péssimo em São Paulo. Tinha caminhão em rua de pedestre, entrega na zona azul fora do horário, descarga em viela intransitável.
Restrições como cidadãs de primeira classe
Mudamos a modelagem: restrições viram filtro antes do otimizador, não penalidade depois. Cada via tem janelas de horário, limite de peso, tipo de veículo permitido, status atual (obra, alagamento, ZMRC).
Fontes de dados
- CET-SP, CET-Rio, EPTC e outras 12 prefeituras com API aberta
- Mapa interno mantido pelo time de operações por região
- Reportes do próprio motorista (rua intransitável)
O que ainda não fazemos bem
Restrição em tempo real fora dos grandes centros é falha — a maioria dos municípios não tem API. Aí dependemos do reporte do motorista, e isso atrasa em 24h. É o nosso próximo trabalho.
Continue lendo.
Ver todos os textos →Como construímos um BI que responde em linguagem natural
Dashboards são bons. Pergunta em linguagem natural sobre os mesmos dados é melhor. Como saímos de protótipo pra produção em 4 meses.
Fraude de ponto não desapareceu — mudou de bolso
App de ponto resolve totem caro mas abre vetor novo. O que aprendemos sobre geofence, biometria de viva e padrões anômalos.
O que acontece quando ronda vira evidência digital
Postos auditáveis em tempo real, laudo pronto pra cliente e supervisor que enxerga o campo. Três meses depois da troca, os números falaram.