NexTool Solutions

Os incidentes que se repetem são o sintoma de um problema que ninguém abriu ainda. No GLPI, perceber que dez tickets da mesma categoria caíram na mesma entidade em duas semanas depende de alguém estar a olhar para o relatório certo na altura 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 os Problemas são a causa raiz por trás de incidentes repetidos. O GLPI tem o itemtype Problema e permite associar incidentes, mas não deteta a recorrência: essa parte é humana. Alguém tem de notar que vários tickets partilham 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 enche-se de 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: "porque é que ninguém viu isto antes?".

Como o Problem Flow funciona

O módulo avalia automaticamente os tickets já resolvidos e fechados, à procura de 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, é criado um Problema ITIL no GLPI, já contextualizado.

• Gatilhos duplos - a avaliação corre em tempo real, ao fechar ou resolver um ticket, e também através de um 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 monitorizada. Várias regras coexistem para cobrir cenários diferentes.
• Âmbito focado - o módulo analisa apenas tickets do tipo Incidente, alinhado com a prática ITIL de associar Problemas a incidentes repetitivos.
• Rastreabilidade completa - cada deteção fica registada 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 perceber o que o Problem Flow faz, vale a pena ver a deteçã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 - precisamente os candidatos a tornarem-se Problema. Execute numa réplica de leitura ou numa janela de baixa utilização:

-- Detecao 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 tornarem-se 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;

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

Funcionalidade do módulo vs comportamento nativo

Como ativar

1. Instale o plugin NexTool no GLPI.
2. Aceda a Configuração > NexTool > Módulos.
3. Ative o módulo Problem Flow.
4. Registe as regras de deteçã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 totalmente na automatização.

O que aprendemos na sustentação

Na sustentação de operações ITIL, o Problem Flow acerta ou falha pela calibragem do limiar, não pela tecnologia. Limiar demasiado baixo e o módulo gera um Problema por categoria por semana, tornando-se ruído que ninguém trata; demasiado alto e nunca dispara, e volta-se à deteção manual. Padronizámos começar conservador, observar o log durante duas ou três semanas e só então apertar. Dois detalhes que só aparecem a operar: 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 à espera de 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á a olhar 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 deteção manual de padrões é impraticável;
• Operações com múltiplas entidades ou equipas distribuídas;
• Gestores que precisam de evidência rastreável 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, produz Problemas em excesso que a equipa não consegue tratar - o efeito colateral é uma fila de Problemas abandonados, pior do que não ter a automatizaçã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 deteção automática e rastreável, fale com a equipa.

Este conteúdo foi produzido com o apoio de inteligência artificial e revisto pela equipa Nextool Solutions.