Os KPIs de logística que todo gestor acompanha no Power BI

Sua operação enxerga o pedido, mas não enxerga a promessa quebrada#

A maioria dos gestores de logística sabe quantos pedidos entrou e quantos saiu. O que eles não sabem, na hora certa, é quantos foram entregues no prazo, completos e sem avaria. Esse buraco entre o que a operação registra e o que o cliente sente é onde os KPIs de logística ganham valor no Power BI. Não é sobre ter mais gráfico, é sobre transformar dados de TMS, WMS e ERP em números que respondem uma pergunta simples: estamos cumprindo a promessa que vendemos?

Neste artigo eu detalho os indicadores que realmente movem a operação, como calcular cada um em DAX e como montar o modelo a partir das suas fontes. Sem enrolação e com uma opinião clara: KPI que ninguém age em cima é dashboard de vaidade.

OTIF é o KPI que resume a promessa ao cliente#

OTIF (On Time In Full) mede o percentual de pedidos entregues dentro do prazo combinado E completos, sem falta de item nem de quantidade. É o indicador mais honesto da logística porque combina duas dimensões que o cliente sente juntas. Um pedido no prazo mas incompleto não é OTIF. Um pedido completo mas atrasado também não é.

O erro comum é calcular OTIF só no nível de linha do pedido. Decida a granularidade antes: por linha de pedido, por pedido inteiro ou por entrega. Cada uma conta uma história diferente, e misturar as três gera discussão infinita em reunião.

Em DAX, com uma tabela fato Entregas que traz DataEntrega, DataPrometida, QtdPedida e QtdEntregue:

OTIF % = DIVIDE( CALCULATE( COUNTROWS(Entregas), Entregas[DataEntrega] <= Entregas[DataPrometida], Entregas[QtdEntregue] >= Entregas[QtdPedida] ), COUNTROWS(Entregas) )

Na prática você vai querer flags calculadas na modelagem (IsOnTime, IsInFull) para não repetir lógica em toda medida. Uma boa modelagem dimensional resolve metade dos problemas de DAX antes de escrever a primeira medida, algo que detalhamos em boas práticas de modelagem e DAX.

OTD, fill rate e lead time contam o que o OTIF esconde#

O OTIF é ótimo como número único, mas péssimo para diagnóstico. Quando ele cai, você precisa saber se foi prazo ou completude. Por isso os gestores acompanham os componentes separados.

OTD (On Time Delivery) isola a dimensão prazo: percentual de entregas dentro da data prometida, independente de estarem completas. Fill rate isola a completude: quanto da quantidade pedida foi de fato atendida, geralmente medido por quantidade ou por valor. Lead time mede o tempo decorrido entre eventos do ciclo, tipicamente do pedido até a entrega, e é a base para prometer prazos realistas.

KPI	O que mede	Fórmula conceitual	Fonte típica
OTD	Pontualidade da entrega	Entregas no prazo / total de entregas	TMS
Fill rate	Completude do atendimento	Qtd entregue / qtd pedida	WMS + ERP
Lead time	Tempo do ciclo	Data entrega menos data pedido	ERP + TMS
OTIF	Prazo e completude juntos	No prazo E completo / total	TMS + WMS + ERP

Fill rate em DAX, ponderado por quantidade:

Fill Rate % = DIVIDE( SUM(Entregas[QtdEntregue]), SUM(Entregas[QtdPedida]) )

Lead time médio em dias:

Lead Time Medio = AVERAGEX( Entregas, DATEDIFF(Entregas[DataPedido], Entregas[DataEntrega], DAY) )

Uma opinião: média de lead time engana. Um cliente que espera cinco dias e outro que espera trinta viram uma média de dezessete que não descreve ninguém. Complemente sempre com mediana e com percentil 90 usando PERCENTILEX.INC, porque a cauda longa é onde mora a insatisfação.

Custo por pedido e por entrega mostram se a eficiência tem preço#

Cumprir prazo queimando frete expresso não é vitória. Por isso todo painel maduro cruza serviço com custo. Os dois recortes mais usados são custo por pedido, que divide o custo logístico total pelo número de pedidos processados, e custo por entrega, que aproxima o dado da rota e do veículo.

O desafio aqui não é DAX, é rateio. Custo de armazenagem, frete, mão de obra e embalagem raramente vêm carimbados por pedido no ERP. Defina o critério de rateio junto com o financeiro e documente. Quando o custo unitário depende de premissa, a premissa precisa estar visível no relatório, não escondida numa medida.

Custo por Pedido = DIVIDE( SUM(fCustos[ValorCusto]), DISTINCTCOUNT(Entregas[PedidoID]) )

Se o custo está numa tabela separada por centro de custo ou por rota, você vai precisar de um modelo estrela bem desenhado com dimensões compartilhadas de calendário, cliente e transportadora. É exatamente o tipo de trabalho que sustenta um projeto sério de Power BI e que a Fynx trata como fundação, não como detalhe.

Avarias, devoluções e acuracidade medem a qualidade da operação#

Serviço rápido e barato não vale nada se a mercadoria chega quebrada ou se o estoque do sistema não bate com o físico. Três indicadores cobrem a qualidade.

Taxa de avarias é o percentual de itens ou pedidos com dano registrado na entrega ou no recebimento. Taxa de devolução mede quanto do que saiu voltou, e vale separar devolução por avaria, por erro de separação e por arrependimento do cliente, porque a causa muda a ação. Acuracidade de inventário compara o saldo do sistema com a contagem física, sendo um dos KPIs mais importantes e mais ignorados, porque estoque errado envenena o fill rate e o OTIF lá na frente.

KPI de qualidade	Numerador	Denominador	Meta operacional comum
Taxa de avarias	Itens avariados	Itens entregues	O mais baixo possível
Taxa de devolução	Itens devolvidos	Itens expedidos	Baixo e com causa mapeada
Acuracidade de inventário	SKUs com saldo correto	SKUs contados	Próximo de 100%

Acuracidade em DAX, comparando saldo sistêmico e contagem física por SKU:

Acuracidade Inventario % = DIVIDE( CALCULATE( DISTINCTCOUNT(fInventario[SKU]), fInventario[SaldoSistema] = fInventario[SaldoFisico] ), DISTINCTCOUNT(fInventario[SKU]) )

Um alerta honesto: acuracidade calculada só sobre SKUs contados esconde o que você não contou. Se o ciclo de contagem cobre 20% do estoque por mês, deixe isso explícito no relatório. Número sem contexto de cobertura induz decisão errada.

Como montar o modelo a partir de TMS, WMS e ERP#

A maior dificuldade da logística no Power BI não é a fórmula, é a integração. Os dados moram em sistemas diferentes, com chaves diferentes e granularidades diferentes. O TMS conhece a entrega e o transporte, o WMS conhece a separação e o estoque, e o ERP conhece o pedido, o cliente e o custo. Sem uma camada que concilie isso, cada KPI vira uma verdade paralela.

O caminho que funciona na prática:

• Extração e conciliação de chaves. Padronize identificadores de pedido, item e cliente entre os sistemas. Muitas vezes o mesmo pedido tem código diferente no TMS e no ERP, e resolver esse de-para é a parte que consome tempo de verdade.
• Modelo estrela. Uma ou poucas tabelas fato (entregas, custos, inventário) cercadas por dimensões conformes de calendário, cliente, produto e transportadora. O motor VertiPaq do Power BI comprime melhor colunas de baixa cardinalidade, então evite trazer texto livre e IDs longos que não serão filtrados.
• Flags e datas na modelagem. Calcule IsOnTime, IsInFull e diferenças de data na camada de dados ou em coluna, não repetindo em cada medida.
• Camada semântica com medidas nomeadas. OTIF, OTD, fill rate e custo unitário como medidas DAX documentadas, reaproveitáveis em qualquer visual.

Para volumes maiores ou muitas fontes, faz sentido tratar a ingestão fora do relatório, com pipelines de verdade. É o território de engenharia de dados, e no Microsoft Fabric, anunciado pela Microsoft em 2023, o modo Direct Lake permite ler tabelas direto do OneLake sem importar nem usar DirectQuery, o que muda a conta de atualização em cenários grandes. Se você está avaliando Fabric para logística, vale ler nossa análise sobre o que é o Microsoft Fabric e se vale a pena.

Um erro que vejo com frequência: puxar tudo do ERP via DirectQuery achando que é tempo real e descobrir que o relatório fica lento e o banco transacional sofre. Na maioria das operações logísticas, atualização importada algumas vezes ao dia atende, e a decisão entre Import, DirectQuery e Direct Lake precisa ser deliberada, não acidental.

Metas, alvos e o que fazer quando o KPI cai#

Indicador sem meta é termômetro sem faixa de febre. Defina alvos por KPI e, idealmente, por cliente ou canal, porque o prazo prometido para um grande varejista não é o mesmo de um pequeno pedido pulverizado. No Power BI, cartões com KPI visual, faixas condicionais e a função de análise por decomposição ajudam o gestor a sair do número agregado e chegar na causa: qual transportadora, qual CD, qual SKU está puxando o OTIF para baixo.

Governança fecha o ciclo. Definição única de cada métrica, controle de quem acessa o quê e conformidade com a LGPD, a Lei nº 13.709/2018, quando o modelo cruza dados de clientes e endereços de entrega. Painel de logística costuma expor dado pessoal de destinatário, e isso exige tratamento. Cobrimos o tema em governança de dados e LGPD no Power BI.

Perguntas frequentes#

Qual a diferença entre OTIF e OTD na prática? OTD mede só a pontualidade da entrega, ou seja, se chegou na data prometida. OTIF exige as duas coisas ao mesmo tempo: no prazo e completo, sem falta de item. Um pedido pode ter OTD bom e OTIF ruim se chegou na data mas com quantidade incompleta. Por isso os dois convivem no painel, o OTIF como número de topo e o OTD para diagnóstico.

Preciso de Microsoft Fabric para montar KPIs de logística ou o Power BI puro resolve? Para a maioria das operações, o Power BI com um bom modelo estrela resolve muito bem, usando licenças por usuário como Power BI Pro ou PPU. Fabric entra quando você tem grande volume, muitas fontes ou necessidade de uma plataforma de dados unificada com capacidade dedicada, medida em Capacity Units e comercializada em SKUs como F2 até F2048. É decisão de arquitetura e custo, não obrigação.

Como calcular lead time se meus dados de data têm horário e fuso diferentes? Padronize tudo para um fuso único na camada de dados antes de calcular, e decida se o lead time é em dias corridos ou úteis. Para dias úteis, use uma dimensão calendário com marcação de feriados e dias trabalhados e calcule contra ela, em vez de um DATEDIFF simples que ignora fins de semana e feriados.

Meu OTIF varia muito dependendo de quem calcula. Como padronizar? Isso quase sempre é falta de definição de granularidade e de fonte da data prometida. Defina por escrito se o OTIF é por linha, por pedido ou por entrega, e qual sistema é a fonte oficial de cada campo. Depois transforme essa definição em medidas DAX únicas na camada semântica, para que ninguém recalcule por conta própria em planilha.

Como trato custo logístico se o ERP não me dá custo por pedido? Você define critérios de rateio junto com o financeiro para armazenagem, frete e mão de obra, e deixa a premissa visível no relatório. Não invente precisão que o dado não tem. É melhor um custo por pedido aproximado e transparente do que um número exato e falso.

Vale a pena conectar o TMS ou WMS direto no Power BI via DirectQuery? Raramente vale mirar em tempo real via DirectQuery sobre o sistema transacional, porque penaliza performance do relatório e do próprio sistema operacional. Na maioria dos casos, extrair para uma camada intermediária e atualizar em modo Import algumas vezes ao dia atende à decisão logística. Reserve DirectQuery ou Direct Lake para casos com justificativa clara de frescor de dado.

Comece pelo KPI que dói, não pelo dashboard bonito#

Os melhores painéis de logística que a Fynx entregou começaram com uma pergunta incômoda: por que o cliente reclama de atraso se o sistema diz que entregamos? OTIF, OTD, fill rate, lead time, custo unitário, avarias, devoluções e acuracidade são as respostas quando os dados de TMS, WMS e ERP conversam num modelo confiável. Escolha um indicador que hoje causa dor, calcule direito, ponha meta e aja. O resto do dashboard vem depois.

Se você quer sair da planilha e montar isso com fundação de dados sólida, fale com a gente.