Limites dos relatórios do Wialon e análise em SQL

Relatórios prontos servem para o controle operacional, mas a análise avançada costuma exigir dimensões flexíveis, cruzamentos próprios e comparações históricas que são mais fáceis em SQL.

Reconheça os limites cedo

Os relatórios nativos do Wialon fazem várias coisas bem: resumos operacionais ao vivo do estado atual da frota, visões por motorista e por veículo para a revisão diária, e registros de eventos de geocerca para conformidade e comprovação de entrega. Para um gestor de frota que precisa saber o que aconteceu hoje com um veículo ou um motorista específico, os relatórios do Wialon são rápidos e eficazes. Os problemas aparecem quando as perguntas ficam mais complexas.

A agregação entre frotas é onde os relatórios do Wialon quebram primeiro. Não dá para comparar com facilidade a eficiência de combustível entre categorias de veículo, regiões e períodos numa visão só. Dimensões de tempo próprias — trimestres fiscais, períodos sazonais, janelas de contrato de um cliente — não existem de forma nativa. Cruzar dados de telemetria com dados de negócio externos — custos do seu ERP, SLAs de clientes do seu CRM, histórico de manutenção do seu CMMS — é impossível dentro do motor de relatórios do Wialon. Análise por coorte e comparações ano contra ano obrigam a exportar os dados e refazer a análise do zero toda vez.

O ciclo de exportar para planilha é o sintoma mais claro de dívida analítica. Alguém exporta um relatório do Wialon para CSV, transforma os dados no Excel com fórmulas e tabelas dinâmicas, monta um gráfico e manda um PDF por e-mail para a diretoria. Quando a diretoria faz a pergunta seguinte, o analista volta ao Wialon, roda um relatório um pouco diferente, exporta de novo, transforma de novo e manda de novo. Esse ciclo consome horas por semana e produz resultados que não são reproduzíveis, nem auditáveis, nem compartilháveis além de quem montou a planilha. Quanto mais ele dura, mais difícil fica sair dele, porque o conhecimento da empresa se acumula em planilhas individuais e não em lógica compartilhada e versionada.

Entenda o que o SQL abre

A força do SQL para análise de frota está na dimensionalidade flexível. Uma única consulta pode agrupar o consumo de combustível por categoria de veículo, região, cliente atribuído e mês do calendário ao mesmo tempo. Acrescentar uma dimensão nova — digamos, o tempo de experiência do motorista — é um JOIN e uma cláusula GROUP BY, não um novo modelo de relatório. A profundidade histórica fica trivial: anos de dados vivem em tabelas indexadas que devolvem resultado em segundos, e não em sessões de extração relatório por relatório que levam minutos cada.

Poder cruzar telemetria com dados de negócio transforma as perguntas que você consegue responder. Em vez de saber quanto combustível o veículo 42 consumiu na semana passada, você calcula o custo por entrega, por cliente, por região e por trimestre, compara com os compromissos de SLA e identifica quais contratos não são lucrativos ao preço atual do combustível. Os planos de manutenção do CMMS cruzam com o uso real de cada veículo para ajustar quando vale a preventiva. Os registros de treinamento de motoristas cruzam com as notas de direção econômica para medir se o treinamento adiantou.

Funções de janela e os padrões analíticos do SQL permitem detectar tendências que nos relatórios do Wialon são impraticáveis. Uma média móvel de 30 dias do consumo por categoria de veículo revela uma degradação gradual que os relatórios diários não enxergam. Rankings por percentil identificam pontos fora da curva que não aparecem na média da frota. As funções lag e lead mostram a variação de semana para semana sem comparar duas exportações na mão. Visões materializadas pré-calculam esses resultados para que os painéis carreguem na hora, mesmo sobre conjuntos grandes.

Construa uma camada SQL governada

Definir as métricas de forma central em SQL significa que cada time da organização usa a mesma fórmula para a mesma métrica. Taxa de utilização, custo por quilômetro, percentual de entregas no prazo: cada uma tem uma definição SQL, mantida num lugar só, produzindo um número só. Parece óbvio, mas sem governança é notavelmente comum que operações e financeiro calculem a mesma métrica de jeitos diferentes, produzindo números em conflito que derrubam a confiança nos dois.

A governança pede três disciplinas. Primeiro, todas as definições SQL de métricas vivem em arquivos versionados — não na configuração da ferramenta de painéis, não num histórico de consultas improvisadas, não na coleção pessoal de trechos de alguém. Segundo, mudanças numa definição passam por revisão de pares, como o código. Se alguém quer mudar a fórmula de utilização para excluir fins de semana, essa mudança é revisada pelo impacto a jusante antes de ser integrada. Terceiro, toda métrica tem documentação: o que mede, como é calculada, de que fontes sai, que limitações conhecidas tem e de quem ela é.

A implementação prática é simples. Crie um diretório de métricas no seu repositório de análise. Cada métrica ganha um arquivo SQL que define uma visão ou uma visão materializada. O arquivo leva um comentário de cabeçalho explicando a métrica. Mudanças exigem um pull request revisado por pelo menos uma pessoa que entenda o contexto de negócio e uma que entenda o modelo de dados. Esse processo acrescenta talvez meia hora por mudança e evita horas de confusão quando os números não batem.

Desenhe a migração dos relatórios para SQL

A migração dos relatórios do Wialon para a análise em SQL deve seguir em três fases, cada uma com critérios de aceite claros. A fase um replica em SQL os relatórios que já existem e valida que os números batem. Ela é deliberadamente conservadora: ainda não se acrescenta capacidade nenhuma, só se prova que o pipeline SQL produz os mesmos resultados. Rode os dois sistemas em paralelo por pelo menos quatro semanas. Se os números divergirem mais de 1%, investigue e corrija antes de seguir.

A fase dois estende a análise com dimensões e recortes que os relatórios do Wialon não conseguem dar. É aí que o valor fica visível: comparações entre frotas, tendências ano contra ano, dados de negócio cruzados, análise por coorte. Essa fase deve ser guiada por uma lista priorizada de perguntas que hoje ninguém consegue responder. Comece pelas três análises mais pedidas, construa em SQL e apresente os resultados ao lado dos relatórios atuais para mostrar o que se ganhou.

A fase três aposenta as exportações manuais e treina os usuários na ferramenta de BI. É a fase mais difícil porque exige mudar um hábito. Gente que há anos exporta CSV e monta análise no Excel precisa aprender um fluxo novo. Dê sessões práticas, não só documentação. Monte painéis salvos que repliquem as análises de Excel mais comuns. Marque uma data para aposentar a exportação manual e cumpra: se os dois caminhos ficarem abertos para sempre, o antigo sempre vence, porque é o conhecido.

• Fase um: replicar os relatórios existentes em SQL e validar que os números batem dentro de 1% por quatro semanas.
• Fase dois: acrescentar as análises que o Wialon não dá — entre frotas, ano contra ano, com dados de negócio cruzados.
• Fase três: aposentar as exportações manuais, treinar e marcar uma data de corte que seja cumprida.

Mantenha o relatório operacional separado da análise

O Wialon deve continuar sendo o sistema das decisões operacionais ao vivo. Posições atuais, alertas de geocerca ativos, leituras de sensores em tempo real, status de despacho: são perguntas operacionais que precisam de latência abaixo de um segundo e dados vivos. O Wialon foi feito para isso e faz bem. Tentar replicar visões operacionais ao vivo dentro de um armazém SQL acrescenta complexidade sem necessidade e vai sempre ficar atrás do sistema de origem.

O armazém SQL atende as perguntas estratégicas: tendências de custo dos últimos seis meses, dimensionamento da frota para o orçamento do ano que vem, comparação de desempenho entre regiões, rentabilidade por cliente. Essas perguntas toleram latência de minutos ou horas porque alimentam decisões tomadas por semana ou por mês, não na hora. Misturar cargas operacionais e estratégicas num sistema só degrada as duas: as consultas ao vivo competem por recursos com as agregações analíticas, e nenhuma roda bem.

Estabeleça uma regra de roteamento que a organização inteira entenda: se a pergunta é sobre o que está acontecendo agora, use o Wialon. Se é sobre o que aconteceu na semana passada, no mês passado ou no ano passado, use o painel SQL. Se ela compara dados de vários sistemas (telemetria mais ERP, telemetria mais CRM), vai para o SQL, porque o Wialon não cruza com dado externo. Essa regra elimina a ambiguidade que leva gente a construir análises concorrentes em ferramentas diferentes.

Monte a stack de análise

O PostgreSQL é a escolha padrão para o armazém, a menos que você tenha um motivo concreto para escolher outra coisa. Ele aguenta bem as cargas analíticas de uma frota (milhões de linhas, agregações complexas), tem ferramentas excelentes em volta e a maioria dos engenheiros já conhece. Para frotas que geram telemetria de alta frequência — atualizações de GPS abaixo de um minuto em milhares de veículos — o TimescaleDB acrescenta otimizações específicas de série temporal (hypertables, agregados contínuos, compressão) em cima do PostgreSQL sem trocar de linguagem de consulta.

A escolha da ferramenta de BI depende da maturidade técnica da sua organização. O Metabase é o caminho mais rápido para painéis de autoatendimento para gente não técnica: gera SQL a partir de cliques e suporta relatórios agendados. O Grafana é melhor para painéis voltados à operação, com visualização de série temporal e alertas. Tableau e Looker são ferramentas corporativas que acrescentam governança, segurança por linha e incorporação sofisticada, mas trazem custo de licença e complexidade de implantação que um time pequeno não precisa.

Use o dbt (data build tool) para administrar as transformações se você tiver mais do que um punhado de visões SQL. O dbt permite definir transformações como arquivos SQL com rastreamento de dependências, rodá-las em ordem, testar as saídas e documentar a linhagem do dado cru até a métrica final. Ele dá estrutura ao que de outro modo vira um emaranhado de visões interdependentes que ninguém tem coragem de mexer. O princípio-chave é manter a stack simples o bastante para um engenheiro sustentar. Se a sua stack analítica exige um time de plataforma dedicado, ela é complexa demais para o tamanho da sua frota.

Meça a adoção

Construir a stack não é a linha de chegada: a adoção é. Acompanhe a quantidade de consultas por usuário por semana para entender quem de fato está usando. As visualizações de painel dizem quais relatórios são acessados; os visitantes únicos dizem quão amplo é o uso. Um painel com 500 visualizações e 2 visitantes únicos é uma ferramenta pessoal, não uma capacidade da organização. Um com 50 visualizações e 20 visitantes únicos tem adoção ampla.

A métrica de adoção mais importante é o tempo entre a pergunta e a resposta. Antes da migração, quanto demorava responder uma pergunta de custo entre frotas? Se levava três dias de trabalho no Excel e agora leva cinco minutos de navegação num painel, isso é ganho de produtividade mensurável que você consegue reportar. Faça uma pesquisa trimestral com os interessados: eles se autoatendem ou ainda abrem chamado para o time de dados? A meta é autoatendimento para o rotineiro, com o time de dados construindo análises novas em vez de rodar as antigas.

Faça uma revisão trimestral de análise para conter a proliferação de painéis. Liste cada painel e cada consulta salva, anote quais foram abertos nos últimos 90 dias e arquive o resto. Painéis sem uso geram carga de manutenção e confundem usuários novos, que não sabem qual está vigente. Ao mesmo tempo, incentive a exploração: criar uma consulta ad hoc e salvá-la como painel pessoal precisa ser fácil. A revisão trimestral é o mecanismo que impede que a exploração pessoal vire bagunça organizacional.

Sair do ciclo de exportações exige ter os dados num banco que você possa consultar, com as definições de métricas sob revisão e não dentro de uma pasta de trabalho. É isso que o FleetSQL faz: a extração, o agendamento e o esquema, entregues num PostgreSQL que é seu.