Dashboard Compras e Suprimentos no Power BI: KPIs, layout e o que medir

Compras vira reunião de opinião quando o número não é o mesmo para todos#

Na maioria das empresas, a área de suprimentos toma decisão de milhões olhando para planilhas que ninguém confere. O comprador tem a dele, o gerente pede outra, o financeiro extrai a terceira do ERP, e cada corte de data ou de categoria muda o resultado. Quando a diretoria pergunta quanto a área economizou no trimestre, a resposta demora três dias e vem com asterisco. Um dashboard compras e suprimentos Power BI existe para acabar com essa cena: uma fonte só, definições combinadas, e o número que aparece na tela sendo o mesmo que o comprador, o gerente e o CFO enxergam ao mesmo tempo.

Este artigo é prático. Vou mostrar quais KPIs realmente importam em compras, como organizar o layout para que ele conte uma história e não vire um mural de gráficos, de onde vêm os dados, e como escrever as medidas DAX centrais sem cair nas armadilhas clássicas de contexto de filtro. O foco é montar algo que a área use na segunda-feira de manhã, não um protótipo bonito para a demonstração.

O dashboard compras e suprimentos Power BI cobre economia, nível de serviço e risco#

O erro mais comum é tratar compras como se fosse só "quanto gastamos". Gasto é metade da história. Um painel que ajuda de verdade responde a três perguntas que a área precisa defender toda semana: estamos comprando bem (economia), estamos sendo bem servidos (nível de serviço do fornecedor) e estamos expostos a que (risco). Todo KPI abaixo se encaixa em uma dessas três caixas. Se um indicador não cabe em nenhuma, ele provavelmente é vaidade e vai poluir a tela.

A lista de indicadores essenciais de um painel de suprimentos é enxuta e cobre os oito que sustentam a decisão:

KPI	O que mede	Bloco
Savings	Economia gerada frente a preço de referência, cotação anterior ou orçamento	Economia
Spend por categoria	Distribuição do gasto por família de materiais e serviços	Economia
Lead time de compra	Tempo entre a requisição e a colocação do pedido	Nível de serviço
Prazo de entrega do fornecedor	Tempo entre o pedido e o recebimento efetivo	Nível de serviço
Cobertura de estoque	Quantos dias o estoque atual sustenta o consumo	Risco
Ruptura de estoque	Frequência e itens em que faltou material	Risco
Concentração de fornecedor	Quanto do spend está preso a poucos fornecedores	Risco
Aderência a contrato	Quanto do gasto passou por contrato negociado versus compra avulsa	Economia

Repare que savings, spend por categoria e aderência a contrato falam de economia. Lead time de compra e prazo de entrega do fornecedor falam de nível de serviço. Cobertura de estoque, ruptura e concentração de fornecedor falam de risco. Essa é a espinha dorsal do painel, e é também como o layout vai ser dividido.

Savings é o KPI que dá briga, então defina antes de medir#

Savings parece simples e é o número mais discutido de qualquer área de compras. O problema nunca é o cálculo, é o baseline. Economia contra o quê: o preço da última compra, uma tabela de referência, o orçamento aprovado ou a média de cotações da rodada atual. Cada escolha muda o resultado e cada uma tem defensor. A recomendação honesta é fixar a definição com o dono da área antes de abrir o Power BI e deixar essa regra explícita no painel, num tooltip ou numa caixa de texto. Um savings que ninguém consegue explicar de onde veio é um savings que a diretoria não vai acreditar, por mais bonito que esteja o cartão.

Lead time e prazo de entrega são coisas diferentes, não misture#

Lead time de compra e prazo de entrega do fornecedor viram um número só quando o modelo é preguiçoso, e aí a área perde a capacidade de agir. Lead time de compra é interno: quanto a sua operação demora entre receber a requisição e efetivamente colocar o pedido no fornecedor. Se está alto, o problema é seu, geralmente aprovação parada ou cotação lenta. Prazo de entrega do fornecedor é externo: quanto ele demora do pedido ao recebimento. Se está alto, a conversa é com o fornecedor. Separar os dois deixa claro onde está o gargalo e para quem cobrar. É a diferença entre "nosso processo é lento" e "esse fornecedor entrega atrasado".

O dado vem do ERP, e a modelagem decide se o painel presta#

Toda essa informação nasce no ERP. Requisição, pedido de compra, recebimento, nota fiscal, cadastro de fornecedor, contratos e movimentação de estoque são tabelas que já existem em qualquer SAP, Protheus, Oracle ou similar. O dashboard não inventa dado, ele organiza o que o ERP já registra. O trabalho de verdade está entre extrair essas tabelas e servi-las ao Power BI de um jeito que as medidas funcionem.

A regra de ouro é modelo estrela. Uma tabela fato para os pedidos e recebimentos, e dimensões para fornecedor, categoria, centro de custo, material e, obrigatoriamente, uma tabela calendário marcada como data. Sem isso, inteligência de tempo em DAX simplesmente não funciona direito, e você vai passar a vida caçando por que o acumulado do mês está errado. Se a extração do ERP é pesada ou os dados vêm sujos, esse tratamento não pertence ao Power Query do relatório, pertence a uma camada de dados anterior. Fazer transformação séria no Power Query de cada relatório é dívida técnica que cobra juros. Vale desenhar uma engenharia de dados que entregue as tabelas já limpas, com granularidade certa, e deixar o Power BI cuidar de modelo e medidas.

Um ponto que sempre aparece: a granularidade da fato precisa ser decidida no começo. Pedido de compra tem cabeçalho e item, e recebimento é parcial na vida real. Se você fixar a fato no nível de item de pedido e tratar recebimentos numa fato separada, os cálculos de prazo de entrega e ruptura ficam limpos. Misturar granularidades na mesma tabela é o caminho mais curto para números que não batem.

O layout separa economia, nível de serviço do fornecedor e risco em blocos#

Layout não é decoração, é a ordem em que a pessoa lê a decisão. Um painel de compras que funciona respeita a mesma divisão dos KPIs e conduz o olho de cima para baixo, do resumo ao detalhe. A estrutura que uso na prática tem três blocos claros mais uma linha de contexto no topo.

Área do painel	O que fica ali	Por que ali
Topo	Filtros de período, categoria, centro de custo e fornecedor, mais os cartões de spend total e savings	Contexto e os dois números que abrem qualquer conversa
Bloco economia	Spend por categoria, evolução de savings e aderência a contrato	Responde "estamos comprando bem"
Bloco nível de serviço	Lead time de compra, prazo de entrega do fornecedor e ranking de pontualidade	Responde "estamos sendo bem servidos"
Bloco risco	Concentração de fornecedor, cobertura de estoque e itens em ruptura	Responde "onde estamos expostos"

A tentação de espremer tudo numa página só é forte e quase sempre é errada. Prefira uma página de visão geral com os cartões e um gráfico por bloco, e páginas de detalhe para quem quer mergulhar em categoria, fornecedor ou item. O comprador vive no detalhe, a diretoria vive na visão geral, e o mesmo modelo serve os dois se a navegação estiver desenhada. Se você quer referências de organização visual e navegação, vale olhar exemplos de dashboards montados nesse padrão de blocos.

Uma opinião que economiza retrabalho: cor com significado. Vermelho, amarelo e verde só devem aparecer onde existe meta ou faixa aceitável definida, como pontualidade de fornecedor ou cobertura de estoque. Colorir gráfico só porque fica bonito treina a área a ignorar cor, e aí quando a cor importa de verdade ninguém repara.

As medidas DAX de savings e lead time médio são o coração do modelo#

Aqui é onde a maioria dos painéis quebra. Não por falta de gráfico, por medida escrita errada. Duas delas concentram quase todos os problemas: savings e lead time médio.

Savings, no formato mais comum, é a diferença entre um preço de referência e o preço efetivamente pago, multiplicada pela quantidade. O ponto de atenção é que você quer somar isso item a item e depois totalizar, nunca calcular sobre valores já agregados, senão o total mente. Por isso o SUMX, que itera linha a linha da fato:

Savings =
SUMX (
    Pedidos,
    ( Pedidos[PrecoReferencia] - Pedidos[PrecoPago] ) * Pedidos[Quantidade]
)

O preço de referência precisa vir de uma regra combinada, seja um campo trazido do ERP, seja uma tabela de preços de referência relacionada. Não invente o baseline dentro do DAX na base do "achei que era". Se a regra de negócio muda por categoria, ela mora numa dimensão, não numa constante escondida na medida.

Lead time médio é a segunda pedra no sapato. A conta em si é banal, a média da diferença em dias entre duas datas. O erro clássico é deixar o total ser distorcido por linhas sem data de pedido ou de recebimento, que viram zero e derrubam a média. Trate isso explicitamente:

Lead Time Medio (dias) =
AVERAGEX (
    FILTER (
        Pedidos,
        NOT ISBLANK ( Pedidos[DataPedido] )
            && NOT ISBLANK ( Pedidos[DataRecebimento] )
    ),
    DATEDIFF ( Pedidos[DataPedido], Pedidos[DataRecebimento], DAY )
)

O FILTER que remove linhas sem data é o detalhe que separa uma média confiável de uma média que a área vai desmentir na primeira conferência. A mesma lógica vale para separar lead time de compra (da requisição ao pedido) de prazo de entrega (do pedido ao recebimento): são duas medidas com o mesmo esqueleto e pares de datas diferentes. Escreva as duas, nunca uma só.

Duas boas práticas fecham o assunto. Primeiro, medidas base e medidas derivadas. Calcule spend, quantidade e savings uma vez, em medidas simples, e construa savings percentual, ticket médio e afins reaproveitando essas bases. Repetir SUMX em dez lugares é convite para inconsistência. Segundo, entenda contexto de filtro antes de sair usando CALCULATE. Metade dos números que "não batem" em compras é CALCULATE alterando o contexto de um jeito que o autor não percebeu. Se você vai levar o modelo a sério, o tempo investido em modelagem e boas práticas de DAX volta em painel que não precisa de conserto toda semana.

O que medir depende de quem vai olhar, então priorize#

Nem toda empresa precisa dos oito KPIs no dia um. Se a dor é gasto fora de controle, comece por spend por categoria e aderência a contrato, porque é onde o dinheiro vaza sem contrato negociado. Se a dor é operação travada, comece por lead time e prazo de entrega, que expõem gargalo interno e fornecedor lento. Se a dor é falta de material parando a produção, comece por cobertura e ruptura de estoque. Concentração de fornecedor e savings entram na sequência, quando a área já confia no dado e quer defender resultado para a diretoria. Construir tudo de uma vez costuma atrasar a entrega e diluir o valor. Melhor um painel que responde uma pergunta bem do que oito respostas pela metade.

Perguntas frequentes#

Qual a diferença entre lead time de compra e prazo de entrega do fornecedor? Lead time de compra é o tempo interno, entre a requisição chegar e o pedido ser colocado no fornecedor. Prazo de entrega do fornecedor é o tempo externo, entre o pedido colocado e o recebimento do material. O primeiro mede a agilidade do seu processo, o segundo mede a pontualidade do fornecedor. Separar os dois mostra onde está o gargalo e com quem falar para resolver.

De onde vêm os dados do dashboard de compras? Do ERP. Requisições, pedidos de compra, recebimentos, notas, cadastro de fornecedor, contratos e movimentação de estoque já estão registrados lá, seja SAP, Protheus, Oracle ou outro. O painel não cria dado, ele organiza e cruza o que o ERP guarda. O trabalho está em extrair essas tabelas, limpar e servir ao Power BI num modelo que as medidas consigam calcular sem distorção.

Como calcular savings sem que o número seja contestado? Fixe o baseline antes de abrir o Power BI. Defina com o dono da área contra o que a economia é medida, preço de referência, cotação anterior ou orçamento, e deixe essa regra visível no painel. A medida em DAX usa SUMX para somar a diferença item a item, e o preço de referência vem de um campo ou tabela combinada, nunca de um valor inventado dentro da fórmula.

Preciso do modelo estrela mesmo em um painel pequeno? Sim, e principalmente nele. Uma fato de pedidos e recebimentos, dimensões para fornecedor, categoria, centro de custo e material, e uma tabela calendário marcada como data. Sem isso, inteligência de tempo em DAX falha e os acumulados saem errados. O modelo estrela não é excesso de engenharia, é o que faz as medidas funcionarem de forma previsível quando a base cresce.

Devo colocar todos os KPIs em uma página só? Não. Uma página de visão geral com os cartões de spend e savings mais um gráfico por bloco de economia, nível de serviço e risco, e páginas de detalhe para categoria, fornecedor e item. A diretoria vive na visão geral, o comprador vive no detalhe, e o mesmo modelo serve os dois quando a navegação está desenhada. Espremer tudo numa tela só transforma o painel num mural que ninguém lê.

Por quais KPIs começar se a empresa nunca teve painel de compras? Pela dor. Gasto fora de controle começa por spend por categoria e aderência a contrato. Operação travada começa por lead time e prazo de entrega. Falta de material começa por cobertura e ruptura de estoque. Entregue um bloco que responde uma pergunta bem, gere confiança no dado, e só então avance para os demais indicadores.

Um painel de compras bom é o que a área confia, não o mais bonito#

No fim, o valor de um dashboard de suprimentos não está no número de gráficos, está na confiança. Quando o comprador, o gerente e o financeiro olham o mesmo savings, o mesmo lead time e a mesma cobertura de estoque, e ninguém precisa exportar planilha para conferir, a reunião de compras deixa de ser debate de opinião e vira decisão baseada em fato. Isso se constrói com fonte única no ERP, modelo estrela bem feito e DAX escrita com cuidado, não com sorte.

Se você quer montar esse painel do jeito certo desde o começo, ou consertar um que já não bate os números, fale com a gente e veja como estruturamos projetos de Power BI de compras que a área usa de verdade.