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

O service desk vive de planilha e a diretoria não sabe se a TI entrega#

A área de TI gera dado o tempo todo. Cada chamado abre um ticket, cada servidor reporta status a cada minuto, cada mudança fica registrada no sistema. Mesmo assim, quando o CIO precisa mostrar para o board se a TI está entregando, alguém passa a tarde exportando o ITSM para o Excel e montando um gráfico que estará velho amanhã. Um bom dashboard ti Power BI existe para acabar com esse ritual, unindo o dado do service desk, do monitoramento e do controle de custos em um modelo único, para você parar de discutir de onde saiu o número e começar a decidir o que fazer com ele.

Este artigo é para quem gerencia operação de TI, não para quem quer um painel bonito na parede da sala. Vou tratar dos indicadores que mostram se a TI cumpre o combinado, de onde cada dado nasce, de como o layout muda conforme quem olha, e das medidas DAX que sustentam MTTR e disponibilidade sem gambiarra.

O que um dashboard ti Power BI precisa medir de verdade#

Painel de TI que mostra só "quantos chamados entraram" não ajuda ninguém a gerir. A gestão de serviços vive de poucos indicadores, mas cada um precisa de definição escrita e cálculo sempre igual. Estes sustentam a maioria das operações de TI.

KPI	O que mede	Como costuma ser calculado
Disponibilidade (uptime)	Fração do tempo em que o serviço ficou no ar	Tempo disponível dividido por tempo planejado
Volume de incidentes	Quantidade de chamados no período	Contagem de tickets por dia, semana ou mês
Categoria de incidentes	Onde os problemas se concentram	Contagem por tipo, sistema ou grupo resolvedor
MTTR	Tempo médio de reparo de um incidente	Soma do tempo de resolução dividido por número de incidentes
Aderência a SLA	Cumprimento do prazo acordado	Chamados no prazo dividido por total de chamados
Backlog	Chamados em aberto acumulados	Contagem de tickets sem resolução na data
Custo de TI	Gasto da área contra orçamento	Custo realizado por serviço, projeto ou centro de custo
Satisfação	Percepção do usuário com o atendimento	Média de CSAT ou pesquisa pós atendimento

Um ponto separa projeto sério de painel de vitrine: cada número desses precisa de uma regra acordada com quem opera. "Tempo de resolução" para o service desk pode não ser o mesmo que "tempo de resolução" para o cliente interno, porque um conta a pausa de espera pelo usuário e o outro não. Se você não fechar a definição antes de modelar, o dashboard vira palco de discussão em vez de ferramenta de decisão. Essa disciplina é o coração de qualquer trabalho de Power BI bem feito.

Disponibilidade e uptime são a base do painel de infraestrutura#

De todos os KPIs, disponibilidade é o mais direto e, ao mesmo tempo, o mais fácil de calcular errado. A definição parece óbvia: quanto do tempo o serviço ficou no ar. O detalhe está no denominador. Você mede contra 24 horas por 7 dias, ou contra a janela de serviço acordada, tirando fora a manutenção programada? Serviço crítico costuma ser medido em regime contínuo, e a diferença entre 99,9% e 99,5% de uptime, embora pareça pequena, representa horas de indisponibilidade por ano. Por isso a definição precisa vir antes da fórmula: o painel só é confiável quando todo mundo mede a mesma coisa.

De onde vem o dado: ITSM e monitoramento#

O dashboard de TI não tem uma fonte só, e é aí que os projetos tropeçam. Cada indicador puxa de um sistema diferente, e o trabalho é conciliar tudo em uma chave comum, normalmente serviço, sistema afetado e período.

Fonte	O que fornece	KPIs que alimenta
ITSM (service desk)	Tickets, categorias, prazos de SLA, grupos resolvedores, datas de abertura e fechamento	Volume, categoria, MTTR, aderência a SLA, backlog
Monitoramento	Estado dos serviços, eventos de indisponibilidade, tempo no ar de servidores e aplicações	Disponibilidade, uptime
Financeiro e contratos	Orçamento, custo de licenças, contratos de terceiros, rateio por serviço	Custo de TI
Pesquisa de satisfação	Nota de CSAT, respostas pós atendimento	Satisfação

O ITSM, sistema de gestão de serviços de TI, é a fonte mais rica para o lado de atendimento, porque nele mora o ciclo de vida do chamado: quando abriu, quem pegou, qual a categoria, quando resolveu e se estourou o SLA. Ferramentas como ServiceNow, Jira Service Management, GLPI ou Zendesk expõem esse dado por API ou banco, e é dali que saem volume, MTTR, backlog e aderência a SLA.

O monitoramento é outro mundo. Ele não sabe nada de chamado, mas sabe se o servidor respondeu ao ping, se a aplicação estava de pé, se o serviço caiu às três da manhã. É a fonte da disponibilidade real, e o erro clássico é tentar tirar uptime do ITSM, que só enxerga o serviço quando alguém abre um ticket reclamando. Cada sistema no seu lugar: ITSM para o que a equipe fez, monitoramento para o que aconteceu com a infraestrutura.

Juntar essas fontes de forma sustentável raramente cabe no Power Query do relatório. Puxar API do ITSM, exportação do monitoramento e planilha de custos tudo dentro do refresh é frágil: qualquer instabilidade de uma fonte quebra a atualização inteira. O caminho robusto é uma camada de dados que recebe, limpa e concilia antes, e o Power BI lê tabelas fato prontas. Sem essa base, o painel quebra na primeira semana e volta todo mundo para o Excel.

O layout muda conforme o público: operação e gestão#

Layout de dashboard de TI não é decoração, é resposta a uma pergunta simples: quem vai olhar isso, e para decidir o quê. Dois públicos usam o mesmo dado de forma oposta, e tentar servir os dois na mesma tela é o jeito mais rápido de não servir nenhum. Por isso eu separo em duas visões conectadas.

A operação precisa de detalhe e tempo curto#

A camada de operação é para o líder de service desk e para quem está no plantão. Ela responde "o que precisa da minha atenção agora". Aqui entram o backlog aberto por prioridade, a fila de chamados perto de estourar o SLA, os incidentes em aberto por grupo resolvedor e o mapa de serviços que o monitoramento aponta como fora do ar. É uma visão de curtíssimo prazo, atualizada com frequência, com filtro por analista, por categoria e por sistema. O objetivo não é contemplar tendência, é agir: pegar o chamado certo antes de furar o prazo.

A gestão precisa de tendência e comparação com meta#

A camada de gestão é para o coordenador, o gerente e o CIO. Ela responde "a TI está entregando dentro do combinado e dentro do orçamento". Aqui os cartões de KPI mostram disponibilidade do mês, MTTR, aderência a SLA e satisfação, cada um com o valor atual e a comparação com a meta e com o período anterior. Abaixo, a tendência de volume de incidentes ao longo dos meses, o Pareto de categorias que mais geram chamado, e o custo de TI contra o orçamento. É visão de médio prazo, para reunião de resultado, não para apagar incêndio.

Um bom dashboard mantém essas duas camadas no mesmo modelo semântico, mudando só a página e o nível de detalhe. E uma opinião de quem já viu isso dar errado muitas vezes: resista a colocar tudo numa tela só. Painel que tenta ser operacional e executivo ao mesmo tempo vira um amontoado que ninguém usa. Duas páginas limpas valem mais que uma página lotada.

As medidas DAX de MTTR e disponibilidade#

Os dois indicadores mais temidos do painel de TI, MTTR e disponibilidade, são na verdade simples em um modelo dimensional bem feito. Assumindo uma tabela fato de incidentes com data de abertura, data de resolução e um sinalizador de SLA cumprido, e uma tabela fato de disponibilidade com minutos planejados e minutos de indisponibilidade, o padrão é este.

O MTTR, tempo médio de reparo, é a soma do tempo de resolução dividida pela quantidade de incidentes. Uso DATEDIFF para calcular a duração de cada chamado e SUMX para iterar linha a linha.

MTTR (horas) =
DIVIDE(
    SUMX(
        FatoIncidentes,
        DATEDIFF(
            FatoIncidentes[DataAbertura],
            FatoIncidentes[DataResolucao],
            HOUR
        )
    ),
    COUNTROWS ( FatoIncidentes )
)

Repare no uso de DIVIDE em vez do operador de divisão: ele evita erro quando não há incidentes no filtro, comum em um dia sem chamado de um serviço específico. A mesma medida responde por sistema, por categoria e por grupo resolvedor sem reescrever nada, porque o filtro vem da dimensão.

A disponibilidade é a fração do tempo planejado em que o serviço ficou no ar. Com os minutos de indisponibilidade vindos do monitoramento, a medida fica curta e legível com uma variável para cada parcela.

Disponibilidade % =
VAR MinutosPlanejados = SUM ( FatoUptime[MinutosPlanejados] )
VAR MinutosParada = SUM ( FatoUptime[MinutosIndisponivel] )
RETURN
DIVIDE(
    MinutosPlanejados - MinutosParada,
    MinutosPlanejados
)

A aderência a SLA segue a mesma lógica enxuta: dos chamados do período, quantos cumpriram o prazo acordado. Basta um sinalizador booleano na fato, preenchido na camada de dados no momento em que o chamado fecha.

Aderência a SLA % =
DIVIDE(
    CALCULATE(
        COUNTROWS ( FatoIncidentes ),
        FatoIncidentes[DentroDoSLA] = TRUE()
    ),
    COUNTROWS ( FatoIncidentes )
)

O backlog, por sua vez, é uma contagem de chamados ainda abertos numa data, algo que costuma pedir cuidado com a tabela calendário para responder "quantos tickets estavam em aberto no fim de cada mês".

Backlog Aberto =
COUNTROWS(
    FILTER(
        FatoIncidentes,
        FatoIncidentes[DataResolucao] = BLANK()
    )
)

O segredo aqui não está na esperteza da medida, está no modelo por trás dela: tabela fato na granularidade certa, dimensões compartilhadas de serviço, categoria, grupo e data, e uma tabela calendário marcada como tabela de datas. Com esse desenho, as medidas ficam curtas e o painel voa. Para aprofundar, reunimos o que aprendemos em campo no guia de boas práticas de modelagem DAX.

Erros que derrubam um dashboard de TI#

Os mesmos tropeços se repetem, então vale listar para você não repetir.

O primeiro é medir MTTR sem tratar o tempo de espera pelo usuário. Se o chamado ficou três dias parado aguardando resposta do solicitante, esse tempo entra no seu MTTR e infla o número sem culpa da equipe. Ou você mede o tempo líquido de trabalho, descontando as pausas, ou deixa explícito que o indicador inclui espera. O que não pode é misturar as duas coisas em serviços diferentes e comparar.

O segundo é confundir disponibilidade percebida com disponibilidade medida. O monitoramento diz que o servidor estava no ar, mas o usuário não conseguia usar o sistema porque a aplicação travou. Se o seu uptime só olha infraestrutura e ignora a experiência de quem usa, o painel mostra verde enquanto o telefone do service desk toca. Monitore o serviço do ponto de vista de quem consome, não só do host.

O terceiro é categoria de incidente bagunçada. Quando metade dos chamados cai em "outros" ou "diversos", o Pareto de categorias perde o sentido e você não descobre onde investir. Lista de categorias curta, revisada de tempos em tempos, é chata de manter e absolutamente crítica para o painel valer alguma coisa.

O quarto é abandonar o painel depois do go-live. A TI muda: entra sistema novo, muda o SLA do contrato, o time cresce. Dashboard de TI é organismo vivo, e sem uma frente de sustentação de BI ele apodrece em poucos meses e volta todo mundo para a planilha exportada na mão.

Perguntas frequentes#

Preciso de uma ferramenta de ITSM cara para montar o dashboard?

Não. O dashboard funciona com qualquer ITSM que exponha o dado por API ou banco, e isso inclui opções gratuitas ou de baixo custo como o GLPI. O que importa é ter os campos certos preenchidos com disciplina: data de abertura, data de resolução, categoria, prioridade e o prazo de SLA. Ferramenta cara com dado mal preenchido rende um painel pior que ferramenta simples com processo bem cuidado.

Como calculo o MTTR em DAX sem me perder?

Use DATEDIFF para achar a duração de cada chamado entre abertura e resolução, some tudo com SUMX e divida pela contagem de incidentes usando DIVIDE, que protege contra denominador zero. O trabalho difícil não é a fórmula, é decidir se o tempo de espera pelo usuário entra ou sai da conta. Feche essa regra com a operação antes de escrever a medida.

Disponibilidade eu tiro do ITSM ou do monitoramento?

Do monitoramento. O ITSM só sabe que um serviço caiu quando alguém abre um chamado reclamando, o que subestima a indisponibilidade real. O monitoramento observa o serviço de forma contínua e registra a queda mesmo que ninguém perceba na hora. Use o ITSM para o lado de atendimento e o monitoramento para o uptime, cada fonte no que ela faz bem.

Um painel só resolve para a operação e para a diretoria?

Um modelo só resolve, um layout só não. A operação precisa de detalhe e prazo curto, a diretoria precisa de tendência e comparação com meta. O caminho é manter as duas visões no mesmo modelo semântico e separar em páginas diferentes, com o nível de detalhe adequado a cada público. Tentar espremer tudo numa tela entrega um painel que nenhum dos dois usa.

Como coloco o custo de TI no mesmo painel dos chamados?

Trazendo o dado financeiro para uma tabela fato própria, ligada às mesmas dimensões de serviço e de tempo do resto do modelo. O custo raramente sai do ITSM, ele vem do financeiro, de contratos e de licenças, e por isso precisa de conciliação por serviço ou centro de custo antes de entrar. Com essa chave comum, você cruza custo com volume de incidentes e responde quanto custa sustentar cada serviço.

Com que frequência devo atualizar o dashboard de TI?

Depende da camada. A visão de operação, que apoia ação no plantão, pede atualização frequente, de hora em hora ou perto disso, para a fila de chamados refletir a realidade. A visão de gestão, usada em reunião de resultado, funciona bem com atualização diária. Dimensione a frequência pela decisão que ela apoia e não pague complexidade por uma latência que ninguém aproveita.

Comece pelo dado, não pela tela#

Dashboard de TI bom é resultado de dado conciliado entre ITSM, monitoramento e financeiro, KPI com definição fechada e um layout que respeita quem vai decidir. A tela é a parte fácil. O trabalho de verdade está em unir essas fontes em um modelo confiável, escrever MTTR e disponibilidade em DAX uma vez só e separar a visão da operação da visão da gestão. Se você quer sair da planilha exportada na mão e ter uma visão real de uptime, SLA e custo da sua TI, fale com a gente e vamos desenhar isso para a sua área.