NexTool Solutions

Indicador bom é aquele cuja origem você consegue apontar no banco. Este guia mostra quais KPIs de Service Desk realmente valem a pena acompanhar no GLPI, de qual tabela e coluna cada número sai, quais faixas usamos como referência e as armadilhas que já distorceram decisões em ambientes que sustentamos para clientes.

Antes do KPI, o modelo de dados

O erro que mais vemos ao assumir um GLPI existente é medir "por cima": comparar datas cruas em vez de usar os campos que o próprio GLPI já calcula. Cada chamado na tabela glpi_tickets carrega colunas estatísticas prontas, as mesmas que o módulo de Estatísticas consome:

• takeintoaccount_delay_stat - segundos até a primeira tomada de conhecimento (base do tempo de resposta / TTO).
• solve_delay_stat - segundos até a solução, já descontando o tempo em "Pendente" e ajustado pelo calendário de trabalho da entidade (base do TMR / TTR).
• waiting_duration - total de segundos que o chamado ficou em espera.
• time_to_resolve e time_to_own - os prazos (deadlines) do SLA de resolução e de atendimento.
• status - o estado do chamado, que define o que entra ou não no backlog.

Isso muda tudo: o TMR calculado como solvedate - date é diferente (e sempre maior) do que sai de solve_delay_stat, porque a subtração bruta soma madrugadas, fins de semana e pausas. Escolher a coluna certa já é metade do trabalho.

Os KPIs que importam e onde cada um mora

Não é sobre ter dez indicadores no painel; é sobre ter os que geram ação. A matriz abaixo liga cada KPI à sua fonte técnica no GLPI e a uma faixa de referência honesta. Faixa, e não meta universal: o número justo depende do contrato e do tipo de operação.

Extraindo os números direto do banco

O módulo de Estatísticas (em Assistência) responde bem para consulta pontual e para explorar por categoria, grupo, técnico e SLA. Mas ele não versiona o histórico mês a mês nem cruza vários indicadores em uma única linha comparável. Quando precisamos do retrato consolidado que entra no relatório mensal dos clientes, vamos ao banco com um usuário somente-leitura:

-- KPIs do mês corrente em uma única linha (usar usuário somente-leitura)
-- Base: glpi_tickets, os mesmos campos que o módulo Estatísticas consome
SELECT
    COUNT(*)                                                AS volume,
    SUM(status NOT IN (5,6))                                AS backlog,
    ROUND(AVG(NULLIF(takeintoaccount_delay_stat,0))/60, 1) AS tto_min,
    ROUND(AVG(NULLIF(solve_delay_stat,0))/3600, 1)         AS tmr_horas,
    ROUND(
      100 * SUM(solvedate IS NOT NULL AND solvedate <= time_to_resolve)
          / NULLIF(SUM(time_to_resolve IS NOT NULL AND solvedate IS NOT NULL), 0)
    , 1)                                                    AS sla_ttr_pct
FROM glpi_tickets
WHERE is_deleted = 0
  AND date >= DATE_FORMAT(CURDATE(), '%Y-%m-01');

Reabertura não tem coluna própria: ela vive no histórico de mudanças de estado. Em glpi_logs, uma reabertura é o chamado que saiu de Solucionado (status 5) e voltou para atendimento. O log guarda o valor como "5 Solucionado", então filtramos pelo prefixo numérico para não depender do idioma da instalação:

-- Reaberturas do mês: chamados que saíram de Solucionado (5) e voltaram
-- para atendimento. Em glpi_logs, id_search_option 12 = campo status
SELECT COUNT(DISTINCT items_id) AS reabertos
FROM glpi_logs
WHERE itemtype = 'Ticket'
  AND id_search_option = 12
  AND old_value LIKE '5 %'
  AND new_value REGEXP '^[123] '
  AND date_mod >= DATE_FORMAT(CURDATE(), '%Y-%m-01');

Automatizando a coleta mensal

Rodar a consulta na mão todo dia 1 não escala. Agendamos a extração com o próprio cron do sistema, apontando para um arquivo de credenciais .cnf (chmod 600) para nunca deixar senha na linha de comando, e guardamos o CSV fora do GLPI. Assim nasce a série temporal que o painel nativo não guarda:

# /etc/cron.d/glpi-kpi  ->  dia 1 às 06:00, como www-data
# Credenciais no arquivo .cnf (chmod 600), nunca na linha de comando
0 6 1 * * www-data /usr/bin/mysql --defaults-file=/etc/glpi/kpi-ro.cnf glpi \
  < /opt/glpi-kpi/kpi_mensal.sql >> /var/log/glpi-kpi/kpi-$(date +\%Y-\%m).csv 2>&1

Metas: faixas honestas, não números mágicos

• Cumprimento de SLA (TTR): acima de 90-95% é saudável para a maioria dos contratos. 100% constante costuma indicar SLA folgado demais, não excelência.
• Reabertura: abaixo de 5%. Acima disso, investigue solução incompleta ou fechamento apressado para "bater" o prazo.
• Resolução no N1: 70-80%. Abaixo de 60%, falta capacitação ou a categorização está ruim; muito acima de 90%, desconfie de chamados complexos mal classificados.
• Satisfação (CSAT): acima de 4,0/5,0, mas sempre lida junto com a taxa de resposta da pesquisa.

Armadilhas que já viraram plantão

Na sustentação de ambientes de clientes, a primeira coisa que fazemos ao assumir um GLPI que já rodava é não confiar no painel nativo até validar a base. Em um cliente com volume alto de chamados por mês, o TMR "oficial" parecia ótimo até percebermos que boa parte dos tickets tinha o mesmo usuário como autor e técnico já na abertura: auto-atribuição que zera o takeintoaccount_delay_stat e mascara o tempo real de resposta. Padronizamos a extração via SQL agendado justamente porque o módulo de Estatísticas não guarda histórico mês a mês; sem série temporal, você compara com a memória, não com dado.

As armadilhas de campo que mais atrapalham a leitura:

• Medir TMR por diferença de datas. solvedate - date infla o número: entram madrugadas, fins de semana e tempo em "Pendente". Use solve_delay_stat, que o GLPI já ajusta pelo calendário.
• Confundir Solucionado com Fechado. Se há fechamento automático após X dias, medir só status = 6 esconde os solucionados aguardando confirmação. O backlog precisa excluir 5 e 6.
• Celebrar TTO baixo de auto-atribuição. Chamado aberto já atribuído zera o tempo de resposta; o número cai sem a operação ter melhorado em nada.
• Ler satisfação sem taxa de resposta. Quando só quem ficou insatisfeito responde, a média engana. Cruze satisfaction com quantas pesquisas foram efetivamente respondidas.

Se o seu GLPI mostra números que ninguém confia, o problema raramente é o GLPI: é a base e a forma de extrair. A sustentação de GLPI da NexTool inclui a modelagem desses indicadores e o relatório mensal consolidado que a liderança lê sem precisar de planilha.

Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.