NexTool Solutions

Um bom indicador é aquele cuja origem se consegue apontar na base de dados. Este guia mostra quais KPIs de Service Desk valem mesmo a pena acompanhar no GLPI, de que tabela e coluna sai cada número, que intervalos usamos como referência e as armadilhas que já distorceram decisões em ambientes que mantemos 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 pedido na tabela glpi_tickets traz colunas estatísticas prontas, as mesmas que o módulo de Estatísticas consome:

• takeintoaccount_delay_stat - segundos até à primeira tomada de conhecimento (base do tempo de resposta / TTO).
• solve_delay_stat - segundos até à 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 pedido esteve em espera.
• time_to_resolve e time_to_own - os prazos (deadlines) do SLA de resolução e de atendimento.
• status - o estado do pedido, que define o que entra ou não no backlog.

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

Os KPIs que importam e onde cada um vive

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

Extrair os números direto da base

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 não versiona o histórico mês a mês nem cruza vários indicadores numa única linha comparável. Quando precisamos do retrato consolidado que entra no relatório mensal dos clientes, vamos à base com um utilizador só de leitura:

-- KPIs do mês atual numa única linha (usar utilizador só de 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');

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

-- Reaberturas do mês: pedidos que saíram de Resolvido (5) e voltaram
-- para atendimento. Em glpi_logs, id_search_option 12 = campo estado
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');

Automatizar a recolha mensal

Correr a consulta à mão todo o dia 1 não escala. Agendamos a extração com o próprio cron do sistema, apontando para um ficheiro de credenciais .cnf (chmod 600) para nunca deixar a 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 ficheiro .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: intervalos honestos, 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 um SLA folgado demais, não excelência.
• Reaberturas: abaixo de 5%. Acima disso, investigue solução incompleta ou fecho apressado para "cumprir" o prazo.
• Resolução no N1: 70-80%. Abaixo de 60% aponta para falta de capacitação ou má categorização; muito acima de 90%, desconfie de pedidos complexos mal classificados.
• Satisfação (CSAT): acima de 4,0/5,0, mas sempre lida em conjunto com a taxa de resposta do inquérito.

Armadilhas que já viraram piquete

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

As armadilhas de terreno que mais atrapalham a leitura:

• Medir o TMR por diferença de datas. solvedate - date inflaciona 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 Resolvido com Fechado. Se há fecho automático após X dias, medir só status = 6 esconde os resolvidos a aguardar confirmação. O backlog tem de excluir 5 e 6.
• Celebrar um TTO baixo de auto-atribuição. Pedido aberto já atribuído zera o tempo de resposta; o número cai sem a operação ter melhorado em nada.
• Ler a satisfação sem a taxa de resposta. Quando só quem ficou insatisfeito responde, a média engana. Cruze satisfaction com quantos inquéritos foram efetivamente respondidos.

Se o seu GLPI mostra números em que ninguém confia, o problema raramente é o GLPI: é a base e a forma de extrair. A manutenção de GLPI da NexTool inclui a modelação destes indicadores e o relatório mensal consolidado que a gestão lê sem precisar de folha de cálculo.

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