Roteirização de Distribuição
O projeto foi desenvolvido para distribuidores que operam por meio de uma rede de revendedores de campo. Cada revendedor é responsável por uma carteira de clientes e por prospectar novos pontos dentro de seu território — mas sem uma estrutura inteligente de rotas, o resultado era inevitável: revendedores cruzando os mesmos corredores no mesmo dia, sem coordenação e sem eficiência. O sistema foi construído para resolver esse problema de forma granular: cada revendedor recebe, de forma automática, a rota do dia calculada com base na sua posição, nos clientes a visitar e nos territórios dos demais — impedindo sobreposições e maximizando o aproveitamento de cada jornada sem que o gestor precise intervir diariamente nesse processo.
- —Revendedores percorrendo o mesmo corredor no mesmo dia sem ciência um do outro
- —Rota definida por hábito ou intuição — sem critério de eficiência ou território
- —Nenhuma estrutura para prospectar uma cidade nova sem ter pisado nela antes
- —Gestor consumindo tempo operacional para monitorar e corrigir rotas diariamente
- —Ausência de registro de pontos visitados, rejeitados ou inativos por revendedor
- +Rota diária gerada automaticamente para cada revendedor, sem intervenção do gestor
- +Cruzamento de todas as rotas ativas para eliminar sobreposição de território
- +Mapeamento completo de uma cidade nova antes de qualquer visita presencial
- +Customização granular por revendedor: perfil, área e histórico de atendimento
- +Máximo aproveitamento da jornada de cada revendedor em campo
Rota calculada, território garantido, jornada aproveitada
O sistema utiliza a API de Rotas do Google para calcular a sequência ideal de visitas de cada revendedor com base em distância real, tempo de deslocamento e janela de atendimento. O ponto central da solução está no cruzamento de rotas: ao gerar o planejamento do dia, o sistema enxerga simultaneamente todos os revendedores ativos e distribui os pontos de forma que nenhum corredor seja coberto por mais de um deles — eliminando o problema de sobreposição de forma estrutural, sem depender de comunicação entre os próprios revendedores.
Para a prospecção de novas cidades, o sistema resolve uma limitação real do modelo de distribuição: o revendedor não precisa ter estado em um lugar para entender a demanda daquele mercado. A partir de uma varredura geográfica em grade — dividindo a cidade em células e consultando cada uma delas — o sistema retorna todos os pontos de interesse do setor, com avaliação, volume de atividade e localização precisa. O revendedor recebe uma rota estruturada para uma cidade que nunca visitou, com os pontos mais relevantes já priorizados.
A customização é granular: o histórico de cada revendedor — pontos visitados, clientes convertidos, locais marcados como inativos — é mantido no backend e incorporado automaticamente ao planejamento futuro. O sistema não sugere o que já foi descartado. O gestor deixa de ser um intermediário diário na construção de rotas e passa a atuar apenas nas decisões estratégicas de território.
| Módulo | Função operacional |
|---|---|
| Rota diária automática | Geração automática da rota de cada revendedor para o dia, com sequência otimizada e território garantido frente aos demais ativos. |
| Cruzamento de rotas | Visão consolidada de todos os revendedores em campo, impedindo que dois cubram o mesmo corredor no mesmo dia. |
| Prospecção de cidade nova | Varredura geográfica em grade que mapeia todos os pontos de interesse de um município antes de qualquer visita presencial, com rota já estruturada. |
| Customização por revendedor | Histórico individual de visitas, conversões e pontos inativos incorporado ao planejamento — sem retrabalho e sem sugestões redundantes. |
| Exportação e integração | Rota exportável diretamente para o Google Maps e lista de pontos em Excel para uso no CRM ou planejamento de equipe. |
Manutenção Preventiva
via Telemetria — Sig@
O projeto partiu de uma realidade comum em operações industriais: dados de telemetria existem, mas não estão estruturados o suficiente para gerar decisão. Máquinas de naturezas distintas, com peças e ciclos de manutenção diferentes, transmitindo sinais via vibração e movimento — e nenhum sistema capaz de interpretar esses dados de forma padronizada e automática. O trabalho começou antes do algoritmo: na categorização completa das máquinas, das peças e dos parâmetros de cada equipamento, com base nos manuais dos fabricantes. Somente com essa base estruturada foi possível cruzar os dados de telemetria com os limites de manutenção de cada componente e automatizar, via integração com o Sig@, a abertura das ordens de serviço preventivas — sem intervenção humana no ciclo.
- —Telemetria disponível via vibração e movimento das máquinas, mas sem estrutura de interpretação
- —Máquinas e peças sem categorização padronizada para fins de manutenção preventiva
- —Parâmetros de manutenção dos fabricantes não consolidados em nenhum sistema
- —Identificação de manutenções dependente de julgamento manual do operador
- —Abertura de ordens de serviço feita manualmente, sem rastreabilidade estruturada
- +Categorização completa de máquinas e peças com base nos manuais dos fabricantes
- +Estruturação dos dados de telemetria para cruzamento com parâmetros de manutenção
- +Algoritmo que identifica automaticamente quando cada componente requer intervenção
- +Integração com o Sig@ para abertura autônoma das ordens de serviço preventivas
- +100% do processo automatizado — do sinal de telemetria ao ticket no sistema
- +Capacidade de expansão do parque de máquinas sem aumento proporcional de postos de trabalho
Categorização, estruturação e automação: três etapas em sequência
A primeira etapa do projeto foi inteiramente de tratativa de dados. Cada máquina e cada peça relevante foi catalogada com base nos manuais dos fabricantes: tipo de equipamento, componentes críticos, frequência de manutenção recomendada e parâmetros técnicos de operação. Esse trabalho de categorização foi o que viabilizou tudo o que veio depois — sem ele, os dados de telemetria não teriam referência contra a qual ser comparados.
A segunda etapa foi a estruturação da telemetria. Os sensores instalados nas máquinas captam vibração e movimento em tempo real. Esses sinais brutos foram normalizados e organizados de forma que o algoritmo conseguisse lê-los em relação aos limites de cada componente — entendendo quando um equipamento está se aproximando do limiar de manutenção definido pelo fabricante, antes que qualquer falha se manifeste.
A terceira etapa foi a automação via Sig@. Com o diagnóstico gerado pelo algoritmo, um módulo integrado ao sistema acessa o Sig@, identifica o equipamento e o componente, e abre a ordem de serviço preventiva com todos os campos preenchidos. O operador recebe a tarefa estruturada — sem que ninguém precisasse interpretar os dados, tomar a decisão ou navegar pelo sistema manualmente.
| Etapa | O que foi feito |
|---|---|
| Categorização | Levantamento e estruturação de todas as máquinas, peças e parâmetros de manutenção com base nos manuais dos fabricantes — base de referência do algoritmo. |
| Tratativa de dados de telemetria | Normalização e organização dos sinais de vibração e movimento para cruzamento com os limites de manutenção de cada componente catalogado. |
| Algoritmo de previsão | Lógica que identifica, por componente e por equipamento, quando a manutenção preventiva é devida — antes de qualquer falha se manifestar. |
| Integração com Sig@ | Abertura automática da ordem de serviço no Sig@ com máquina, componente, tipo de intervenção e responsável preenchidos pelo sistema. |
| Rastreabilidade | Histórico completo de todas as intervenções preventivas registrado no Sig@, auditável por equipamento, período e tipo de manutenção. |
| Escalabilidade operacional | A automação do ciclo de manutenção permite ampliar o parque de máquinas sem aumento proporcional de postos de trabalho dedicados ao controle preventivo. |
DRP — Planejamento de Reposição
Baseado em Demanda Real
Operações que trabalham com importação de longo prazo — China, França — enfrentam um problema de timing que o modelo tradicional de compras não resolve: quando a decisão de comprar é tomada com base em percepção ou histórico simples, o resultado oscila entre ruptura e excesso. O DRP (Distribution Requirements Planning) desenvolvido neste projeto substitui esse processo por análise estatística do consumo histórico, calibrada pelo lead time real de cada fornecedor. O sistema determina, para cada SKU, o que comprar, em que volume e em qual momento — evitando o overstock, que imobiliza capital sem gerar retorno, e garantindo cobertura adequada mesmo para insumos com ciclos de reposição de 60 dias ou mais. O resultado mensurado foi uma economia de R$ 20 milhões em estoque evitado, com redução de R$ 2 milhões mensais em custo financeiro de capital imobilizado.
- —Decisões de compra baseadas em percepção do comprador ou média histórica não calibrada
- —Overstock recorrente: capital imobilizado em itens com baixo giro ou sem demanda no período
- —Lead time de importação (China e França) não incorporado ao ciclo de reposição
- —Ruptura e excesso coexistindo: falta de um item enquanto outro acumula no armazém
- —Sem visibilidade do ponto ideal de reposição por SKU, categoria ou fornecedor
- +Análise estatística de consumo histórico por SKU com ajuste para sazonalidade
- +Ponto de reposição calculado pelo lead time real de cada fornecedor
- +Alerta de overstock antes da compra ser emitida — não depois do estoque acumular
- +Quantidade ideal de pedido sugerida por item e por ciclo de reposição
- +Dashboard com posição, giro, cobertura e projeção de ruptura por SKU
Da extração de dados ao frontend analítico: camadas em sequência
A construção do sistema seguiu uma progressão deliberada de camadas. A primeira etapa consistiu na conexão ao banco de dados MySQL do cliente, hospedado em um Windows Server local, e no desenvolvimento de scripts Python dedicados exclusivamente à extração dos dados brutos — sem transformação, sem cálculo. Esse isolamento garantiu que a camada de leitura fosse estável e independente das etapas seguintes.
A segunda etapa foram os scripts de processamento: módulos Python separados, cada um responsável por um cálculo específico — consumo por SKU, variação de preço, lead time por fornecedor, projeção de overstock, ponto de reposição. Cada script operava sobre os dados já extraídos, produzindo as métricas que alimentariam o frontend.
O frontend foi desenvolvido em Next.js, conectado diretamente ao backend Python via API, e exibia os dados calculados em dashboards estruturados para o time de compras. O agente de consulta em linguagem natural foi desenvolvido como módulo Python independente, executando no mesmo servidor backend, sem acoplamento ao fluxo principal de cálculo. Todo o ambiente foi containerizado via Docker para deploy na infraestrutura Windows Server do cliente.
Consumo histórico, lead time real e eliminação do overstock
O modelo parte do histórico de consumo de cada SKU e aplica análise estatística para projetar a demanda esperada no ciclo seguinte — ajustando para variações sazonais e descartando oscilações atípicas que distorceriam uma média simples. Com essa projeção, o sistema calcula o ponto exato em que o pedido de reposição deve ser emitido, levando em conta o tempo real que cada fornecedor leva para entregar: um parceiro nacional tem um ciclo; uma importação da China, outro; um fornecedor francês, outro ainda. O sistema trata cada um de forma individualizada.
O indicador central que o DRP combate é o overstock — a compra de volume acima do necessário para o ciclo projetado. Mais do que identificar o excesso depois que ele acontece, o sistema o previne: a sugestão de quantidade de compra é calibrada para manter o estoque dentro de uma faixa eficiente, sem ultrapassar o nível que imobiliza capital e sem cair abaixo do ponto que gera ruptura. A decisão de compra deixa de ser julgamento e passa a ser saída de modelo.
| Dimensão | Como o sistema trata |
|---|---|
| Consumo histórico | Análise estatística por SKU com ajuste de sazonalidade e filtro de outliers — base para a projeção de demanda de cada ciclo. |
| Lead time por fornecedor | Cada fornecedor tem seu prazo real cadastrado. O ponto de reposição é calculado individualmente — importações da China e França têm ciclos distintos e são tratadas como tal. |
| Overstock | O sistema identifica, antes da emissão do pedido, se a quantidade pretendida ultrapassa o necessário para o ciclo projetado — e emite alerta antes que o excesso aconteça. |
| Sugestão de compra | Quantidade ideal de pedido calculada por SKU, por ciclo e por fornecedor — considerando cobertura mínima, estoque de segurança e lead time real. |
| Visibilidade de estoque | Dashboard com posição atual, giro, cobertura em dias e projeção de ruptura por item — para decisão informada sem necessidade de consultas manuais. |