NexTool Solutions

Incidentes que se repetem são o sintoma de um problema que ninguém abriu ainda. No GLPI, perceber que dez chamados da mesma categoria caíram na mesma entidade em duas semanas depende de alguém estar olhando o relatório certo na hora certa. O módulo Problem Flow faz essa leitura sozinho e cria o Problema ITIL automaticamente quando o padrão se confirma.

O problema: a ponte entre incidente e problema é manual

Quem opera ITIL sabe que Problemas são a causa raiz por trás de incidentes repetidos. O GLPI tem o itemtype Problema e permite vincular incidentes a ele, mas não detecta a recorrência: essa parte é humana. Alguém precisa notar que vários chamados têm a mesma categoria, na mesma entidade, na mesma janela de tempo - e só então criar o Problema e ligar os incidentes.

Essa lacuna tem custo. O intervalo entre o padrão surgir e o Problema ser aberto é preenchido por mais incidentes, mais retrabalho e mais carga na fila. Em operações de alto volume, o padrão costuma passar despercebido até o impacto já ser grande - e aí a pergunta do gestor é sempre a mesma: "por que ninguém viu isso antes?".

Como o Problem Flow funciona

O módulo avalia automaticamente os tickets já resolvidos e fechados, procurando concentração por categoria e entidade dentro de uma janela de tempo configurável. Quando o número de ocorrências atinge o limiar da regra, um Problema ITIL é criado no GLPI, já contextualizado.

• Gatilhos duplos - a avaliação roda em tempo real, ao fechar ou solucionar um ticket, e também via cron periódico, garantindo cobertura mesmo em picos de volume.
• Regras configuráveis - cada regra define o número mínimo de tickets, o período de análise, a categoria e a entidade monitorada. Várias regras coexistem para cobrir cenários diferentes.
• Escopo focado - o módulo analisa apenas tickets do tipo Incidente, alinhado à prática ITIL de associar Problemas a incidentes repetitivos.
• Rastreabilidade completa - cada detecção fica registrada no log do módulo, com referência aos tickets que acionaram a regra e ao Problema gerado.

O padrão que o módulo automatiza

Para entender o que o Problem Flow faz, vale ver a detecção feita à mão. A consulta abaixo lista, por categoria e entidade, os incidentes resolvidos ou fechados nos últimos 30 dias e destaca os grupos com cinco ou mais ocorrências - exatamente os candidatos a virar Problema. Rode em réplica de leitura ou em janela de baixo uso:

-- Deteccao MANUAL do padrao que o Problem Flow automatiza:
-- incidentes resolvidos/fechados nos ultimos 30 dias, agrupados por categoria e entidade.
-- Grupos com 5+ ocorrencias sao candidatos a virar um Problema ITIL.
SELECT c.completename          AS categoria,
       e.completename          AS entidade,
       COUNT(*)                AS ocorrencias
FROM glpi_tickets t
JOIN glpi_itilcategories c     ON c.id = t.itilcategories_id
JOIN glpi_entities e           ON e.id = t.entities_id
WHERE t.type = 1                       -- 1 = Incidente
  AND t.status IN (5, 6)               -- 5 = Solucionado, 6 = Fechado
  AND t.is_deleted = 0
  AND t.solvedate >= NOW() - INTERVAL 30 DAY
GROUP BY t.itilcategories_id, t.entities_id
HAVING COUNT(*) >= 5
ORDER BY ocorrencias DESC;

É esse trabalho, repetido a cada janela e para cada regra, que o módulo passa a fazer sozinho e sem depender de alguém lembrar de rodar o relatório.

Recurso do módulo x comportamento nativo

Como ativar

1. Instale o plugin NexTool no GLPI.
2. Acesse Configuração > NexTool > Módulos.
3. Ative o módulo Problem Flow.
4. Cadastre as regras de detecção: categoria, entidade, limiar de tickets e janela de tempo.
5. Acompanhe o log do módulo nas primeiras semanas para calibrar o limiar antes de confiar 100% na automação.

O que aprendemos na sustentação

Na sustentação de operações ITIL, o Problem Flow acerta ou erra pela calibragem do limiar, não pela tecnologia. Limiar baixo demais e o módulo gera um Problema por categoria por semana, virando ruído que ninguém trata; alto demais e ele nunca dispara, e você volta à detecção manual. Padronizamos começar conservador, observar o log por duas ou três semanas e só então apertar. Dois detalhes que só aparecem operando: primeiro, contar tickets ainda abertos infla o número, porque o mesmo incidente reaberto aparece várias vezes - por isso a análise sobre resolvidos e fechados é a correta. Segundo, o erro de campo mais comum é apontar a regra para uma categoria-pai esperando somar os filhos: como a contagem é pela categoria escolhida, incidentes espalhados por subcategorias irmãs não se agrupam, e a regra parece "não funcionar" quando, na verdade, está olhando para o nível errado da árvore.

Para quem é indicado (e quando não usar)

O Problem Flow é indicado para operações que adotam ITIL formalmente e querem fechar a lacuna entre gestão de incidentes e gestão de problemas, em especial:

• Ambientes de alto volume, onde a detecção manual de padrões é impraticável;
• Operações com múltiplas entidades ou equipes distribuídas;
• Gestores que precisam de evidência rastreada de maturidade ITSM para auditoria.

Não faz sentido em operações que ainda não praticam gestão de problemas ou têm volume muito baixo: o limiar raramente será atingido e o módulo fica ocioso. E, mal calibrado, ele produz Problemas em excesso que a equipe não consegue tratar - o efeito colateral é uma fila de Problemas abandonados, pior do que não ter a automação. Calibragem primeiro, confiança depois.

Compatibilidade

• GLPI: 10.0+ e 11.0+
• Plano: Enterprise
• Plugin: NexTool 3.x ou superior

O Problem Flow faz parte do NexTool, plugin modular para GLPI. Para implementar gestão de problemas ITIL com detecção automática e rastreável, fale com a equipe.

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