Dashboard de frota e telemetria no Power BI
Como construir um dashboard de frota no Power BI com telemetria, KPIs de disponibilidade, consumo e custo por km para operações de logística.
Sua frota gera dados o tempo todo, mas quase ninguém consegue lê-los
Se você opera frota própria em logística, os dados já existem. O rastreador manda posição, velocidade e horímetro. A bomba do posto registra litragem. A oficina anota cada ordem de serviço. O problema quase nunca é falta de dado: é que ele está espalhado em cinco sistemas que não conversam, e a decisão acaba saindo de uma planilha que alguém atualiza na sexta à noite. Um bom dashboard de frota no Power BI resolve exatamente esse buraco, unindo telemetria, abastecimento e manutenção em um único modelo para você parar de discutir qual número está certo e começar a discutir o que fazer com ele.
Este artigo é para quem gerencia operação, não para quem quer um relatório bonito na parede. Vou tratar dos KPIs que movem o custo da frota, de como a telemetria entra no Power BI de forma sustentável e das armadilhas que derrubam projeto de BI de logística.
O que um dashboard de frota precisa medir de verdade
Painel de frota que só mostra "quantos veículos temos" não serve para nada. A gestão de frota própria vive de poucos indicadores, mas eles precisam estar bem definidos e calculados sempre da mesma forma. Estes sustentam a operação.
| KPI | O que mede | Como costuma ser calculado |
|---|---|---|
| Disponibilidade da frota | Percentual de veículos aptos a rodar no período | Horas disponíveis dividido por horas de calendário |
| Consumo (km/l) | Eficiência de combustível por veículo ou modelo | Km rodados dividido por litros abastecidos |
| Custo por km | Custo total de operar cada km rodado | Custo total (combustível, manutenção, pneus) dividido por km |
| Preventiva vs corretiva | Equilíbrio entre manutenção planejada e emergencial | Ordens ou custo de preventiva sobre o total de manutenção |
| Ociosidade | Tempo de motor ligado sem deslocamento útil | Horas em marcha lenta ou parado ligado sobre horas totais |
| Utilização | Quanto o ativo efetivamente roda | Km ou horas úteis sobre a capacidade disponível |
Um ponto que separa projeto sério de dashboard de vitrine: cada um desses números precisa de uma definição escrita e acordada com a operação. "Disponibilidade" para o financeiro pode ser diferente de "disponibilidade" para o gestor de manutenção. Se você não fechar a regra antes de modelar, o dashboard vira palco de briga em vez de ferramenta de decisão. Essa disciplina é o coração de qualquer trabalho de Power BI bem feito.
Custo por km é o KPI que ninguém quer ver, mas todo mundo precisa
Custo por km é o indicador mais honesto da operação porque não deixa esconder nada. Ele soma combustível, manutenção, pneus, e quando bem construído também depreciação e mão de obra. É comum um veículo antigo parecer barato porque já foi pago, até você olhar o custo por km e perceber que ele consome o dobro em oficina. Esse KPI só funciona se abastecimento e manutenção estiverem conciliados por placa e por período, que é justamente onde a maioria dos projetos tropeça.
Telemetria é o dado mais rico e o mais traiçoeiro da frota
A telemetria é o que transforma um painel de custos em um painel de operação. Dela vêm posição, velocidade, RPM, horímetro, eventos de frenagem brusca, tempo em marcha lenta e, em muitos rastreadores, consumo instantâneo via CAN bus. É o dado que permite medir ociosidade real, não estimada, e cruzar comportamento de condução com consumo.
O problema é o volume. Um rastreador que emite posição a cada 30 segundos gera milhares de registros por veículo por dia. Multiplique por centenas de veículos e você tem dezenas de milhões de linhas por mês. Jogar isso cru dentro de um modelo do Power BI Desktop é receita para um arquivo lento e frustrante.
A boa notícia é como o Power BI lida com isso quando bem modelado. O motor VertiPaq, por trás do Power BI e do Analysis Services, comprime colunas em memória, e a taxa de compressão depende diretamente da cardinalidade da coluna. Um timestamp com precisão de segundo tem cardinalidade altíssima e comprime mal. A mesma informação truncada para minuto, ou separada em colunas de data e hora, comprime muito melhor. Modelar telemetria é, em boa parte, reduzir cardinalidade sem perder a informação que importa para a decisão.
Pré-agregue antes de chegar no Power BI
A regra prática que aplico: telemetria bruta não é para o modelo analítico. O sinal de segundo a segundo serve para rastreamento ao vivo e para investigar um evento específico, mas o dashboard gerencial trabalha com agregações: km por veículo por dia, horas em marcha lenta por turno, eventos de frenagem por rota. Essa pré-agregação deve acontecer na camada de dados, não no Power BI, e é aí que entra um trabalho de engenharia de dados para preparar as tabelas fato antes que o BI as consuma.
A tabela abaixo resume a decisão de onde cada granularidade vive.
| Granularidade | Uso principal | Onde deve morar |
|---|---|---|
| Sinal bruto (segundos) | Rastreamento ao vivo, perícia de evento | Banco operacional ou data lake |
| Agregado por viagem | Análise de rota, consumo por trecho | Camada de dados / tabela fato |
| Agregado diário por veículo | KPIs gerenciais, tendências | Modelo do Power BI |
| Agregado mensal por frota | Diretoria, comparação de período | Modelo do Power BI |
Como a telemetria entra no Power BI sem virar um monstro
Existem alguns caminhos de integração, e a escolha depende do seu provedor de rastreamento e da maturidade da sua área de dados.
O primeiro é via API do provedor de telemetria. A maioria das plataformas de rastreamento oferece API REST, e o Power Query consegue consumir isso. Funciona para volumes moderados, mas colocar uma extração pesada de API direto no refresh do Power BI costuma ser frágil: qualquer instabilidade do provedor quebra a atualização. Prefiro que a extração aconteça em um processo próprio, gravando em banco ou lake, e o Power BI leia do destino já preparado.
O segundo caminho, mais robusto, é a arquitetura em camadas. A telemetria e as demais fontes (abastecimento, manutenção, ERP) desembocam em um repositório central, passam por transformação e viram tabelas fato limpas. O Power BI conecta nessa camada final. Aqui o Microsoft Fabric, anunciado pela Microsoft em 2023, ficou interessante para logística: os dados vivem no OneLake, e o modo Direct Lake permite que o modelo semântico leia diretamente do OneLake sem precisar importar nem depender de uma consulta DirectQuery tradicional, combinando desempenho de import com dados frescos. Vale lembrar que o consumo no Fabric é medido em Capacity Units, com SKUs que vão do F2 ao F2048, então dimensionar a capacidade certa faz parte do projeto. Se quiser entender se compensa, veja o guia sobre o Microsoft Fabric.
Independentemente do caminho, o modelo dimensional é inegociável. Uma tabela fato de eventos de telemetria, uma de abastecimentos, uma de ordens de manutenção, e dimensões compartilhadas de veículo, motorista, data e rota. Esse desenho em estrela é o que faz o Power BI performar e o que permite o DAX limpo. As decisões de modelagem pesam muito no resultado, então vale fechar as boas práticas antes de sair escrevendo medida.
Exemplos de medidas que você vai precisar
Nada de fórmula gigante, apenas a ideia. Km rodado no período costuma ser algo como SUM(FatoTelemetria[KmDia]). Consumo médio vira DIVIDE([KmRodado], [LitrosAbastecidos]), sempre com DIVIDE para não estourar divisão por zero. Custo por km segue o mesmo padrão, DIVIDE([CustoTotal], [KmRodado]). O segredo não está na complexidade da medida, está em ter as tabelas fato certas e uma tabela calendário marcada como tabela de datas.
Preventiva versus corretiva: o KPI que paga o projeto
De todos os indicadores, o de preventiva contra corretiva costuma dar o retorno mais visível. A lógica é conhecida: manutenção planejada é mais barata, mais previsível e não para o veículo em rota. A corretiva é o oposto, chega na pior hora e arrasta custo indireto de veículo parado.
O dashboard torna isso gerenciável em vez de anedótico. Cruzando telemetria (horímetro, km) com o plano de manutenção, dá para disparar alerta de preventiva por uso real e não por data de calendário, que é como muita frota ainda opera. Um caminhão que rodou pouco no mês não precisa de revisão no mesmo intervalo de um que rodou o dobro. Medir a proporção de preventiva sobre o total, por veículo e por oficina, expõe onde a operação apaga incêndio e onde está no controle.
Aqui cabe uma opinião honesta: esse KPI só melhora se alguém tiver mandato para agir sobre ele. Dashboard não conserta processo de manutenção sozinho, apenas mostra o problema com clareza suficiente para a decisão. Se a governança da operação não acompanha, o painel vira enfeite. Por isso trato projeto de BI de frota como projeto de operação com apoio de dados, não como projeto de TI.
Governança e LGPD não são detalhe em frota
Telemetria de frota tem um componente sensível que muita gente ignora: ela rastreia pessoas. Posição do veículo é, na prática, localização do motorista ao longo da jornada. Isso coloca o dado sob a Lei Geral de Proteção de Dados, a Lei nº 13.709/2018. Não significa que você não pode usar, significa que precisa de base legal, finalidade clara e controle de acesso.
Na prática do dashboard, isso vira desenho de segurança. Quem vê a posição individual de um motorista? O gestor direto talvez, o financeiro provavelmente não precisa. Row-level security no Power BI resolve boa parte disso, restringindo linhas por perfil. Tratamos esse tema com profundidade no artigo sobre governança de dados e LGPD no Power BI, e recomendo desenhar isso no início do projeto, não como remendo depois que a diretoria pergunta quem tem acesso a quê. Uma frente estruturada de governança evita que o painel de frota vire um passivo de compliance.
Erros que derrubam projeto de dashboard de frota
Já vi os mesmos tropeços se repetirem, então vale listar.
O primeiro é conciliação de placa mal feita. Se abastecimento chama o veículo de "ABC1D23" e manutenção de "ABC-1D23", suas junções vão falhar silenciosamente e o custo por km sai errado. Padronização de chave é trabalho chato e absolutamente crítico.
O segundo é confiar cegamente no hodômetro do abastecimento. O frentista digita o hodômetro na hora, e digitação humana erra. Km negativo entre dois abastecimentos ou saltos absurdos pedem regra de limpeza, idealmente cruzando com o km da telemetria, que é mais confiável.
O terceiro é querer tudo em tempo real quando ninguém decide em tempo real. Refresh de hora em hora resolve a gestão da imensa maioria das operações de frota. Tempo real de verdade tem custo e complexidade que só se justificam para casos como torre de controle logístico. Não pague por latência que você não vai usar.
O quarto é abandonar o painel depois do go-live. Provedor de telemetria muda API, a frota cresce, a operação pede indicador novo. Dashboard de frota é organismo vivo, e sem uma frente de sustentação de BI ele apodrece em poucos meses.
Sobre licenças e capacidade, sem enrolação
Para publicar e compartilhar no Power BI Service, cada usuário que consome conteúdo precisa, no modelo clássico, de licença Power BI Pro, ou Premium Per User (PPU) para recursos avançados por usuário. Para frota com muitos consumidores e telemetria pesada, capacidade dedicada faz mais sentido: as SKUs P1 a P5 do Premium e as capacidades do Fabric na família F respondem por isso, permitindo distribuir conteúdo sem licenciar cada leitor individualmente em certos cenários. Não vou cravar preço porque muda e depende de contrato e câmbio: trate qualquer valor como faixa aproximada e confirme na fonte oficial da Microsoft. O ponto durável é que a licença segue o número de consumidores e o volume de dados, não o contrário.
Vale o contexto de mercado: a Microsoft é reconhecida há anos como Líder no Quadrante Mágico do Gartner para plataformas de Analytics e BI, e no Brasil a adoção do Power BI é ampla, muito pela penetração do ecossistema Microsoft. Para logística isso significa mão de obra disponível, comunidade grande e integração natural com Excel, Azure e Power Platform, incluindo automação de alertas e formulários de check-list de veículo.
Perguntas frequentes
Preciso de Microsoft Fabric para fazer um dashboard de frota?
Não. Você constrói um excelente dashboard de frota só com Power BI Pro e um bom modelo dimensional, lendo de um banco ou até de arquivos bem organizados. O Fabric entra quando o volume de telemetria fica alto e você quer o modo Direct Lake lendo do OneLake para combinar frescor de dado e desempenho. Comece pelo modelo e pela qualidade do dado, decida a plataforma depois.
Como faço a telemetria chegar no Power BI se meu rastreador só tem um portal web?
Verifique se o provedor oferece API ou exportação. Quase todos têm API REST, que dá para consumir via Power Query ou, melhor, via um processo de extração que grava em banco. Se só houver exportação manual em CSV, ainda dá para começar, mas planeje automatizar a extração, porque exportação manual não sustenta um painel gerencial no longo prazo.
Qual a diferença entre disponibilidade e utilização da frota?
Disponibilidade mede se o veículo estava apto a operar, ou seja, fora da oficina. Utilização mede se ele efetivamente rodou. Um veículo pode estar disponível e ocioso ao mesmo tempo, o que indica frota superdimensionada, não problema de manutenção. Separar os dois indicadores direciona ação para áreas diferentes.
Consigo calcular custo por km confiável logo no primeiro mês?
Depende da qualidade das suas bases de abastecimento e manutenção. O cálculo é simples, o difícil é conciliar tudo por placa e por período e limpar erros de digitação de hodômetro. Na prática, o primeiro mês costuma ser de higienização de dado, e o número confiável aparece quando as chaves estão padronizadas.
Telemetria de motorista tem problema com a LGPD?
Tem que ser tratada sob a LGPD, sim, porque rastreia a localização de uma pessoa durante a jornada. Isso não impede o uso: exige base legal, finalidade clara e controle de acesso. Na prática você aplica row-level security no Power BI e restringe quem enxerga posição individual. Desenhe isso no início do projeto, não depois.
Vale a pena tempo real em dashboard de frota?
Na maioria dos casos, não. Atualização de hora em hora atende à gestão da frota com folga. Tempo real de verdade só se justifica em cenários como torre de controle logístico, e traz custo e complexidade que a operação típica não aproveita. Dimensione a latência pela decisão que ela apoia.
Comece pelo dado, não pela tela
Dashboard de frota bom é resultado de dado conciliado, KPI bem definido e alguém com mandato para agir sobre o número. A tela é a parte fácil. O trabalho de verdade está em unir telemetria, abastecimento e manutenção em um modelo confiável e sustentável. Se você quer sair da planilha de sexta à noite e ter uma visão real de disponibilidade, consumo e custo por km, fale com a gente e vamos desenhar isso para a sua operação.
Quer aplicar isso na sua empresa?
A Fynx implementa BI, Power BI e Power Platform de ponta a ponta. Conte seu cenário e devolvemos um diagnóstico direto ao ponto.
Falar com um especialista