Maturidade ITSM: Como Avaliar e Evoluir Sua Operação

Como avaliar a maturidade ITSM da sua operação com sinais objetivos extraídos do GLPI (SQL de diagnóstico, matriz por nível e cron em CLI) e evoluir um nível por vez, sem pular etapas.

Neste artigo7 seções

Saber onde você 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 de percepção - e como priorizar os próximos passos de evolução.

Maturidade não se mede por opinião

A pergunta "em que nível estamos?" quase sempre recebe uma resposta emocional: quem apaga incêndio todo dia jura estar no nível 1, e o gestor que aprovou a compra da ferramenta jura estar no nível 4. Os dois estão errados, porque estão medindo sensação, não processo. Maturidade ITSM é o grau de formalização, automação e otimização da gestão de serviços, e ela deixa rastros mensuráveis no banco de dados da ferramenta. Antes de contratar consultoria ou comprar mais módulos, vale extrair esses rastros.

Diagnóstico objetivo: pergunte ao próprio GLPI

Três sinais separam bem uma operação madura de uma imatura: quantos chamados estão realmente categorizados, quantos têm SLA vinculado e quanto tempo levam para ser resolvidos. Rode a consulta abaixo direto no banco (somente leitura) sobre os últimos 90 dias:

-- Sinais de maturidade nos ultimos 90 dias (GLPI 10/11)
SELECT
  COUNT(*)                                               AS total_chamados,
  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 chamados categorizados, esqueça gestão de problemas - você não tem base para agrupar recorrências. Abaixo de 50% com SLA vinculado, seus relatórios de cumprimento medem só 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 ainda é ad-hoc mesmo que exista ferramenta.

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

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

NívelSinal observável no GLPIPróxima ação técnicaMétrica-alvo
1 - Ad-hocSem ferramenta, ou chamados sem categoria/SLAImplantar GLPI, criar entidade e perfis100% dos chamados na ferramenta
2 - RepetívelChamados abertos, mas categoria "Outros" dominaÁrvore de categorias enxuta + SLA inicial>70% categorizados
3 - DefinidoCategorias e SLA em uso; distribuição manualRegras de negócio (atribuição), base de conhecimentoSLA vinculado >90%
4 - GerenciadoMétricas coletadas; cron em CLIGestão de problemas e mudanças, dashboardsSLA cumprido >90%
5 - OtimizadoDecisão por dado; automação maduraAnálise de recorrência, integração com o negócioQueda ano a ano de reincidência

O detalhe de sustentação que falseia toda 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 rodam em modo GLPI (disparadas 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ã, com ninguém logado, nenhum chamado é escalado, e o relatório do dia seguinte mostra um SLA verde que não corresponde à realidade. O erro comum é confiar no dashboard sem checar, em Configuração > Ações automáticas, qual é o modo de execução. A correção é padronizar 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 do console)
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php &>/dev/null

Depois de migrar para CLI, em Ações automáticas troque o campo "Modo de execução" de cada tarefa crítica (queuednotification, slaticket, closeticket) para CLI. Sem isso, você 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 legado, aninhadas em cinco níveis. Na prática, os atendentes não achavam a categoria certa, escolhiam a primeira que aparecia e o campo virava ruído. Recategorizamos o histórico dos últimos meses, cortamos a árvore para pouco mais de duas dezenas de categorias que refletiam o que o time 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 chamado há 90 dias, é candidata a sumir. Categoria demais não mede maturidade; atrapalha a triagem e falseia qualquer análise de recorrência.

Checklist de avaliação rápida

  1. Existe ferramenta de ITSM com todos os chamados dentro dela? (sim = nível 2+)
  2. Mais de 70% dos chamados têm categoria específica, não "Outros"? (sim = nível 3+)
  3. SLA está vinculado e o cron roda em CLI validado? (sim = nível 3+)
  4. Métricas são coletadas e revisadas em reunião fixa? (sim = nível 4+)
  5. Decisões saem do dado, não da percepção? (sim = nível 4+)
  6. Há gestão de problemas ativa reduzindo recorrência? (sim = nível 5)

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

Não tente pular etapas - cada nível se apoia 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 o time realmente usa (na prática, 15 a 25 categorias cobrem a maioria das operações de médio porte) e treinar a triagem. Só depois que a categorização estabiliza é que gestão de problemas passa a fazer sentido, porque você finalmente consegue agrupar incidentes por causa. Se está no nível 1-2, comece pela implantação do GLPI e a 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 recurso novo, e sim de higienizar o que já existe: cron em CLI, categorias enxutas e SLA vinculado a 100% dos tipos de chamado. Esses três ajustes movem a 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 esses indicadores extraídos do seu próprio ambiente, a NexTool faz avaliação e sustentação de GLPI para operações B2B - da configuração básica ao nível otimizado.


Revisado pela equipe NexTool Solutions.

Perguntas Frequentes

Em Configuração > Ações automáticas, a coluna de modo de execução mostra CLI ou GLPI para cada tarefa. Confira também a data da última execução: se ela só avança quando alguém acessa o sistema, o cron está em modo web. O correto é agendar front/cron.php no cron do sistema operacional e definir cada ação crítica como CLI.

Acima de 70% dos chamados em categorias específicas (não "Outros" ou vazio) é o mínimo para sustentar gestão de problemas. Abaixo disso, os agrupamentos por causa ficam pobres e as análises de recorrência perdem confiabilidade.

Os dashboards ajudam, mas dependem de dados bem preenchidos e de cron confiável. Se a categorização é baixa ou o cron roda em modo web, o dashboard mostra números otimistas. Por isso vale cruzar com consultas SQL de leitura direto no banco.

Não. Comece pelas práticas que resolvem as dores mais urgentes (incidentes e requisições), com categorias enxutas e SLA vinculado. Gestão de problemas e de mudanças entram depois, quando os dados de base já são confiáveis.

Comprar recurso novo (automação, IA) antes de higienizar o básico. Sem categorização consistente, SLA vinculado e cron em CLI, qualquer camada avançada herda dados ruins e produz relatórios que não refletem a operação real.

Precisa de ajuda?