Dashboard de nível de serviço (OTIF) no Power BI

O OTIF esconde dois problemas diferentes em um número só#

Toda operação de logística que promete entrega no prazo e com o pedido completo acaba, cedo ou tarde, medindo OTIF. E quase sempre o primeiro dashboard OTIF que nasce na empresa comete o mesmo erro: mostra um percentual único, verde ou vermelho, e para por aí. O problema é que OTIF, On Time In Full, é o produto de dois indicadores que falham por razões distintas. Um pedido pode chegar no prazo mas incompleto, ou completo mas atrasado. O número consolidado não distingue essas duas doenças, e quem olha para ele sabe que está doente sem saber onde dói.

Este artigo mostra como construir um dashboard OTIF no Power BI que separa essas duas dimensões, define o que conta como pontual, expressa as regras em DAX auditável e desce até cliente, rota e transportadora. É a modelagem que faz o indicador sobreviver à primeira reunião em que alguém pergunta "por que esse cliente aparece com 82%?".

OTIF é uma multiplicação, não uma média#

A definição que sustenta o dashboard é simples e precisa ser respeitada em cada linha do modelo. Um pedido só é OTIF quando é, ao mesmo tempo, on-time (dentro da janela de pontualidade acordada) e in-full (com a quantidade completa de todos os itens). Basta falhar em uma das condições para o pedido inteiro ser OTIF igual a zero.

Isso tem uma consequência que muita gente ignora: o OTIF da operação nunca é a média do on-time com o in-full. Ele é o percentual de pedidos que passaram nas duas portas ao mesmo tempo. Se 90% dos pedidos são pontuais e 90% são completos, o OTIF não é 90%: será menor, porque as falhas ocorrem em pedidos diferentes. Modelar o indicador como média infla o número e destrói a confiança quando alguém confere no braço.

A unidade de medida também precisa ser decidida desde o início: OTIF por pedido, por linha (SKU) ou por volume. Cada escolha muda o resultado e responde a uma pergunta diferente:

Unidade de medida	O que ela responde	Quando usar
Por pedido	Quantos pedidos chegaram perfeitos	Visão do cliente, que enxerga o pedido inteiro
Por linha de pedido	Quantos itens/SKU foram atendidos no prazo e completos	Diagnóstico de ruptura de estoque por produto
Por volume (caixas, paletes)	Que fração do volume físico foi perfeita	Operação de armazém e capacidade

Recomendo padronizar o indicador principal por pedido, porque é assim que o cliente sente a dor, e manter as visões por linha e por volume como camadas de diagnóstico. Misturar as três no mesmo cartão gera discussão sem fim sobre qual número é o certo.

A janela de pontualidade é uma decisão de negócio, não um detalhe técnico#

On-time depende de uma pergunta que o BI não responde sozinho: a partir de quando um pedido está atrasado? A resposta quase nunca é "entregou depois da data prometida". Operações reais trabalham com uma janela de tolerância, que precisa estar documentada e refletida na medida.

Há três desenhos comuns de janela, e o modelo tem que saber qual está em vigor:

• Data exata: on-time apenas na data prometida. Raro na prática, comum em contratos rígidos de indústria.
• Janela unilateral: on-time é entregar até a data prometida, sem limite inferior. Entregar antes é aceito.
• Janela bilateral: on-time é entregar dentro de um intervalo, do dia D ao dia D mais 1, ou dentro de um horário agendado. Entregar cedo demais também é falha, porque o cliente não tem doca nem estoque para receber.

A bilateral é a mais realista em varejo e em operações com agendamento de doca: entrega adiantada ocupa espaço, gera devolução e às vezes é recusada. Um dashboard OTIF que trata "antes do prazo" como sucesso automático está mentindo para o gestor de um centro de distribuição com janela apertada.

A janela precisa virar campo no modelo de dados: data prometida, limite inferior aceitável e limite superior aceitável. Se a regra varia por cliente ou por tipo de operação, esses limites vêm de uma tabela de parâmetros e não de um número mágico na fórmula. Deixar o "mais 1 dia" cravado no DAX é o tipo de decisão que ninguém lembra de ter tomado seis meses depois.

As medidas em DAX que fazem o painel funcionar#

Com o modelo estrela montado, uma tabela fato de entregas ligada a dimensões de cliente, rota, transportadora e calendário, as medidas ficam curtas e legíveis. A base é marcar cada pedido com uma flag de on-time e uma de in-full, como colunas calculadas na fato ou medidas que reagem ao contexto.

O padrão parte de três contagens. O total de pedidos entregues, com Pedidos = DISTINCTCOUNT(Fato[PedidoID]). Os pontuais, contando onde a data respeita a janela: Pedidos On Time = CALCULATE([Pedidos], Fato[FlagOnTime] = 1). E os completos, Pedidos In Full = CALCULATE([Pedidos], Fato[FlagInFull] = 1).

O OTIF de verdade não deriva desses dois de forma independente. Ele conta os pedidos que têm as duas flags acesas ao mesmo tempo:

Pedidos OTIF = CALCULATE([Pedidos], Fato[FlagOnTime] = 1, Fato[FlagInFull] = 1)

E os percentuais viram divisões protegidas com DIVIDE, que já trata o denominador zero sem IFERROR:

• % On Time = DIVIDE([Pedidos On Time], [Pedidos])
• % In Full = DIVIDE([Pedidos In Full], [Pedidos])
• % OTIF = DIVIDE([Pedidos OTIF], [Pedidos])

Repare que % OTIF sempre será menor ou igual ao menor entre % On Time e % In Full. Se o OTIF ficar maior que um dos dois, existe erro de modelagem, quase sempre uma flag no grão errado ou uma relação duplicando linhas na fato. Essa é a primeira verificação de sanidade que todo dashboard OTIF deveria ter.

Um detalhe de desempenho importa aqui: o Power BI armazena o modelo no motor VertiPaq, que comprime cada coluna em função da sua cardinalidade. Flags binárias como on-time e in-full comprimem muito bem, porque só têm dois valores. Já uma coluna de data e hora de entrega no segundo tem cardinalidade altíssima e pesa muito. Separar data e hora, ou reduzir o horário para o minuto, deixa o modelo mais leve sem perder a medida da janela. Boas práticas como essa estão no nosso guia de modelagem DAX.

Sem causa de falha, o dashboard vira só um termômetro#

Medir OTIF e parar aí é medir a febre sem investigar a infecção. O painel só gera ação quando cada falha carrega um motivo, o que exige uma dimensão de causa na fato, preenchida na origem ou tratada na engenharia de dados antes de chegar ao modelo. As causas se organizam bem em duas famílias, alinhadas com as duas metades do indicador:

Falha	Causas típicas de atraso (on-time)	Causas típicas de incompletude (in-full)
Origem interna	Separação atrasada no armazém, doca congestionada, roteirização ruim	Ruptura de estoque, avaria no picking, erro de separação
Origem transporte	Veículo quebrado, trânsito, recusa na entrega, falha de agendamento	Extravio de volume, entrega parcial por limite de carga
Origem cliente	Recebimento fechado, janela de doca perdida	Recusa de item, divergência de pedido

Essa taxonomia precisa ser fechada e padronizada. "Outros" é o campo que engole o valor analítico de um dashboard, então quanto menor a fatia de "outros", mais confiável é o diagnóstico. Quando a captura da causa é frágil, o problema não se resolve no Power BI, e sim mais atrás, na engenharia de dados que padroniza e valida o dado antes de ele virar indicador.

Com a causa no modelo, um gráfico de Pareto de motivos por período mostra em segundos onde está a maior perda. E costuma revelar algo político: boa parte das operações descobre que a maior causa de OTIF baixo é interna, não da transportadora que sempre leva a culpa.

O valor está no drill: cliente, rota e transportadora#

Um OTIF consolidado de 88% é quase inútil para agir. A pergunta certa é sempre "88% onde, para quem, em qual trecho". Por isso o dashboard precisa ser desenhado para descer, e três eixos de drill dão conta da maioria das análises logísticas:

• Por cliente: identifica contas onde o nível de serviço está corroendo o relacionamento comercial. Um cliente grande com OTIF sistematicamente abaixo da média é risco de contrato, não estatística.
• Por rota ou região: revela trechos estruturalmente problemáticos, por distância, infraestrutura ou concentração de entregas em janelas apertadas.
• Por transportadora: compara parceiros no mesmo critério, com um cuidado honesto: comparar sem normalizar pelo tipo de rota e pela janela contratada é injusto. Quem só roda entregas urbanas expressas não deveria ser medido com a mesma régua de quem faz interior com janela larga.

No Power BI, esses eixos ganham vida com drill-through que leva da visão agregada até a lista de pedidos que falharam, com data prometida, data realizada, itens faltantes e causa. É quando o dashboard deixa de ser relatório e vira ferramenta de reunião: o gestor clica no cliente crítico e vê quais pedidos derrubaram o número.

Uma tabela de calendário marcada como tabela de datas habilita a leitura de tendência, que importa mais que o valor absoluto: OTIF de 88% pode ser ótimo se veio de 80%, ou alarmante se veio de 94%. Se a operação precisa levar essa leitura para tablets em doca, dá para estender o fluxo com o Power Platform, acionando registro de ocorrência direto do ponto de falha.

Erros comuns que quebram a confiança no dashboard OTIF#

Alguns problemas aparecem em quase todo primeiro dashboard OTIF, e vale nomeá-los antes que virem discussão de credibilidade:

• Grão inconsistente: medir OTIF por pedido no cartão e por linha nos detalhes, sem avisar, faz os números "não baterem".
• Janela indefinida: ninguém escreveu se entregar adiantado conta como on-time, então cada área calcula de um jeito.
• Denominador errado: incluir pedidos cancelados ou ainda não vencidos infla ou desinfla o percentual. Só entra no cálculo o pedido cujo prazo já venceu.
• Fato duplicada: relações muitos-para-muitos mal resolvidas multiplicam linhas e quebram a regra de que OTIF é menor ou igual a on-time e a in-full.

Todos esses são problemas de modelagem e de governança, não de visual. Um painel bonito sobre um modelo errado é pior que uma planilha feia sobre um modelo certo, porque a beleza dá falsa sensação de rigor. Definições únicas, documentadas e versionadas são o papel de uma boa governança de dados, e no OTIF isso se paga na primeira auditoria de contrato.

O que sustenta o painel ao longo do tempo#

Construir o dashboard uma vez é a parte fácil. Mantê-lo confiável enquanto a operação muda, novos clientes entram com janelas próprias e transportadoras trocam, é o desafio real. Isso pede dimensões parametrizadas, medidas comentadas e um processo de atualização que valide o dado antes de publicar, para que o indicador não morra na primeira mudança de regra que ninguém replicou na fórmula.

Vale um enquadramento de mercado, sem invenção de número: o Power BI tem adoção ampla no Brasil, impulsionada pela penetração do ecossistema Microsoft, e a Microsoft é reconhecida como Líder no Quadrante Mágico do Gartner para plataformas de Analytics e BI. Montar OTIF no Power BI raramente é uma aposta arriscada de plataforma: o risco mora na modelagem e na qualidade do dado de origem, não na ferramenta.

Perguntas frequentes#

Qual a diferença entre OTIF e OTD?

OTD (On Time Delivery) mede só a pontualidade, apenas a metade on-time. OTIF exige, além do prazo, que o pedido chegue completo (in-full). Uma operação pode ter OTD alto e OTIF baixo quando entrega no prazo mas com faltas frequentes. Por isso o OTIF é mais exigente e mais próximo da experiência real do cliente.

Devo calcular OTIF por pedido, por linha ou por volume?

Depende da pergunta. Por pedido reflete como o cliente enxerga a entrega e costuma ser o indicador principal. Por linha (SKU) diagnostica ruptura de estoque por produto. Por volume serve à operação de armazém. Padronize um como oficial e mantenha os outros como camadas de diagnóstico no drill.

Entregar antes do prazo conta como on-time?

Não necessariamente. Em operações com agendamento de doca ou estoque enxuto, a entrega adiantada é recusada ou gera custo, então uma janela bilateral trata "cedo demais" como falha. Essa decisão é de negócio e precisa estar documentada e refletida nos limites da janela no modelo, não cravada na medida DAX.

Por que meu % OTIF ficou maior que o % On Time?

Isso é matematicamente impossível quando o modelo está certo, porque OTIF é subconjunto de on-time. Se aconteceu, quase sempre há duplicação de linhas na tabela fato por uma relação mal resolvida, ou uma flag calculada em grão diferente do denominador. Use % OTIF menor ou igual ao menor entre on-time e in-full como teste de sanidade obrigatório.

Preciso do Microsoft Fabric para montar um dashboard OTIF?

Não. Um dashboard OTIF roda bem em Power BI com uma licença Pro ou PPU e um modelo bem construído. O Fabric, anunciado pela Microsoft em 2023 e cobrado por Capacity Units, faz sentido quando o volume de dados e arquiteturas como Direct Lake sobre o OneLake justificam a capacidade dedicada. Para a maioria das operações de porte médio, começar sem Fabric é a decisão certa. Avaliamos esse ponto no artigo sobre o Fabric.

Como garantir que a causa da falha seja confiável?

A causa nasce na operação, não no BI. É preciso uma taxonomia fechada de motivos, captura no ponto onde a falha acontece e validação na engenharia de dados antes de o registro chegar ao modelo. Se a fatia de "outros" for grande, o esforço deve ir para a padronização na origem, não para mais um gráfico no relatório.

Fechamento#

Um bom dashboard OTIF não é o que tem o percentual mais bonito, é o que separa on-time de in-full, define a janela com honestidade, expressa as regras em DAX auditável e desce até o pedido que falhou e o porquê. Se a sua operação já mede OTIF mas ninguém confia no número, o problema está na modelagem e na definição, e isso tem conserto. Fale com a gente e estruturamos o painel do jeito certo, do grão do dado ao drill que resolve a reunião.