NexTool Solutions

Saber onde está é o primeiro passo para saber para onde ir. Este guia mostra como avaliar o nível de maturidade ITSM da sua operação com sinais objetivos extraídos do próprio GLPI - sem depender da perceção - e como priorizar os próximos passos da evolução.

A maturidade não se mede por opinião

A pergunta "em que nível estamos?" recebe quase sempre uma resposta emocional: quem apaga incêndios todos os dias jura estar no nível 1, e o gestor que aprovou a compra da ferramenta jura estar no nível 4. Ambos estão errados, porque medem uma sensação, não um processo. A maturidade ITSM é o grau de formalização, automação e otimização da gestão de serviços, e deixa rastos mensuráveis na base de dados da ferramenta. Antes de contratar consultoria ou comprar mais módulos, vale a pena extrair esses rastos.

Diagnóstico objetivo: pergunte ao próprio GLPI

Três sinais separam bem uma operação madura de uma imatura: quantos pedidos estão realmente categorizados, quantos têm um SLA associado e quanto tempo demoram a ser resolvidos. Execute a consulta abaixo diretamente na base de dados (apenas leitura) sobre os últimos 90 dias:

-- Sinais de maturidade nos ultimos 90 dias (GLPI 10/11)
SELECT
  COUNT(*)                                               AS total_pedidos,
  ROUND(100 * SUM(itilcategories_id > 0) / COUNT(*), 1) AS pct_categorizados,
  ROUND(100 * SUM(slas_id_ttr > 0) / COUNT(*), 1)       AS pct_com_sla_resolucao,
  ROUND(AVG(TIMESTAMPDIFF(HOUR, date, solvedate)), 1)   AS horas_medias_ate_resolver
FROM glpi_tickets
WHERE date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
  AND is_deleted = 0
  AND solvedate IS NOT NULL;

Leitura de campo: abaixo de 70% de pedidos categorizados, esqueça a gestão de problemas - não tem base para agrupar recorrências. Abaixo de 50% com um SLA associado, os seus relatórios de cumprimento medem apenas a fração que tem prazo, não a operação inteira. E se a média de horas até resolver oscila muito de mês para mês, o processo continua ad-hoc mesmo que exista uma ferramenta.

Matriz: nível x sinal no GLPI x ação

Use a matriz para localizar o seu nível pelo que o GLPI mostra hoje, não pelo que gostaria que ele mostrasse:

O detalhe de sustentação que falseia toda a métrica

Na sustentação de ambientes de clientes, o indicador que mais engana é o "SLA cumprido" quando as ações automáticas do GLPI correm em modo GLPI (despoletadas pelo navegador) em vez de CLI. Nesse modo, o recálculo de prazos, as escalações e as notificações só acontecem quando alguém abre uma página do sistema. Resultado: às 3h da manhã, sem ninguém com sessão iniciada, nenhum pedido é escalado, e o relatório do dia seguinte mostra um SLA verde que não corresponde à realidade. O erro comum é confiar no painel sem verificar, em Configuração > Ações automáticas, qual é o modo de execução. A correção é uniformizar tudo em CLI e agendar o cron do sistema:

# /etc/cron.d/glpi  - executa as acoes automaticas a cada minuto
# Vale para GLPI 10 e 11 (front/cron.php e portavel; no 11 evite depender da consola)
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php &>/dev/null

Depois de migrar para CLI, em Ações automáticas mude o modo de execução de cada tarefa crítica (queuednotification, slaticket, closeticket) para CLI. Sem isto, pode estar no nível 4 no papel e no nível 2 na prática.

A armadilha da árvore de categorias herdada

Outro tropeço recorrente: subir de nível achando que "ter muitas categorias" é sinal de maturidade. É o contrário. Já assumimos a sustentação de um ambiente que trazia cerca de 400 categorias importadas de um sistema antigo, aninhadas em cinco níveis. Na prática, os operadores não encontravam a categoria certa, escolhiam a primeira que aparecia e o campo tornava-se ruído. Recategorizámos o histórico dos últimos meses, cortámos a árvore para pouco mais de duas dezenas de categorias que refletiam o que a equipa realmente atende, e só então os relatórios por causa passaram a fazer sentido. A regra prática que usamos: se uma categoria não recebe um pedido há 90 dias, é candidata a desaparecer. Categorias a mais não medem maturidade; atrapalham a triagem e falseiam qualquer análise de recorrência.

Checklist de avaliação rápida

1. Existe uma ferramenta ITSM com todos os pedidos dentro dela? (sim = nível 2+)
2. Mais de 70% dos pedidos estão numa categoria específica, não "Outros"? (sim = nível 3+)
3. O SLA está associado e o cron corre em CLI validado? (sim = nível 3+)
4. As métricas são recolhidas e revistas numa reunião fixa? (sim = nível 4+)
5. As decisões saem do dado, não da perceção? (sim = nível 4+)
6. Há gestão de problemas ativa a reduzir a recorrência? (sim = nível 5)

Plano de evolução: um nível de cada vez

Não tente saltar etapas - cada nível apoia-se no anterior. Se o diagnóstico mostrou categorização baixa, o próximo passo não é comprar IA; é reduzir a árvore de categorias para o que a equipa realmente usa (na prática, 15 a 25 categorias cobrem a maioria das operações de média dimensão) e treinar a triagem. Só depois de a categorização estabilizar é que a gestão de problemas faz sentido, porque finalmente consegue agrupar incidentes por causa. Se está no nível 1-2, comece pela implementação do GLPI e pela configuração básica antes de qualquer automação.

Na nossa experiência de sustentação, o ganho de maturidade mais rápido não vem de uma funcionalidade nova, mas de higienizar o que já existe: cron em CLI, categorias enxutas e um SLA associado a 100% dos tipos de pedido. Estes três ajustes movem uma operação do nível 2 para o 3 em poucas semanas, sem custo de licença adicional.

Se quiser um diagnóstico de maturidade com estes indicadores extraídos do seu próprio ambiente, a NexTool avalia e faz a sustentação de GLPI para operações B2B - da configuração básica ao nível otimizado.

Revisto pela equipa NexTool Solutions.