NexTool Solutions

Os incidentes que se repetem são o sintoma de um problema que ninguém abriu ainda. No GLPI, perceber que dez pedidos de Wi-Fi caíram na mesma filial em duas semanas, ou que o mesmo equipamento voltou à fila pela quarta vez, 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 pedidos partilham a mesma categoria, o mesmo local ou o mesmo equipamento, 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 os pedidos já resolvidos e fechados e deteta incidentes recorrentes com regras no formato do GLPI: categoria, localização, item associado, tipo de solução, prioridade, origem, grupos, requerente e texto do título, da descrição ou da solução. Quando o mínimo de pedidos da regra é atingido no período, é aberto um Problema ITIL no GLPI com os pedidos que o originaram já associados.

• Gatilhos duplos - a avaliação corre sempre que um pedido é resolvido ou fechado e também pela ação automática do GLPI, a cada 6 horas por omissão, garantindo cobertura mesmo em picos de volume.
• Regras no formato do GLPI - cada regra define os critérios, com os mesmos operadores das regras nativas (incluindo "sob", para subcategorias e sublocalizações), o mínimo de pedidos no período, como agrupar (item, local, categoria, grupo técnico, requerente ou setor), o mínimo de requerentes distintos, o intervalo mínimo entre Problemas e como o Problema nasce (título, modelo, categoria, urgência, impacto, grupo técnico, técnico, grupo observador). Várias regras coexistem para cobrir cenários diferentes.
• Um Problema por causa comum - agrupando por local, com um mínimo de 5, cinco incidentes de Wi-Fi na filial Centro e cinco na filial Norte abrem dois Problemas, um por filial. O mínimo de requerentes distintos evita que uma só pessoa dispare o alarme, e o intervalo mínimo impede Problemas repetidos.
• 27 modelos prontos, inativos - equipamento com falhas repetidas; Wi-Fi, impressão, energia e telefonia no mesmo local; e-mail, VPN, autenticação, cópias de segurança, segurança e certificado digital; mesma categoria; soluções de contorno recorrentes; e todo o incidente crítico. Chegam desligados: você ativa apenas o que fizer sentido no seu ambiente.
• Soluções de contorno recorrentes - um dos modelos lê o texto da solução dos pedidos: quando a mesma solução de contorno se repete, passa a Problema, o "candidato a erro conhecido" da ITIL.
• Botão Testar - simula a regra nos pedidos do período sem criar nada: mostra cada grupo, quantos pedidos e requerentes somou face ao mínimo e a pré-visualização do Problema que seria aberto.
• Âmbito alinhado com a ITIL - os 27 modelos prontos contam só incidentes, como recomenda a ITIL; numa regra sua, o tipo do pedido é um critério que você escolhe.
• Rastreabilidade completa - o separador Logs regista, para cada deteção, a regra, o Problema gerado, o grupo e os pedidos que o originaram.

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;

O módulo faz este trabalho sozinho, a cada avaliação e para cada regra, e não apenas por categoria e entidade: vale qualquer combinação de critérios (local, item associado, requerente, texto da solução e os restantes), com a contagem separada pelo agrupamento que escolher e sem depender de alguém se lembrar de correr o relatório.

Funcionalidade do módulo vs comportamento nativo

Como ativar

1. Com o plugin NexTool instalado no GLPI 11, aceda a NexTool > Módulos e ative o Problem Flow.
2. No separador Regras, escolha um dos 27 modelos prontos (chegam inativos) ou crie a sua regra.
3. Clique em Testar: a simulação corre nos pedidos do período e não cria nada.
4. Com o resultado calibrado, ative a regra.
5. Acompanhe o separador Logs para ver que regra abriu cada Problema, para que grupo e com que pedidos.

O que aprendemos na sustentação

Na sustentação de operações ITIL, o Problem Flow acerta ou falha pela calibragem do mínimo de pedidos, não pela tecnologia. Mínimo 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 e passar pelo botão Testar antes de ativar: a simulação mostra, sobre os seus próprios pedidos, cada grupo que a regra formaria, quantos pedidos e requerentes somou face ao mínimo e a pré-visualização do Problema. O ajuste faz-se ali, sem criar nada, em vez de esperar semanas de log. Dois detalhes que só aparecem a operar: primeiro, contar pedidos 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 era apontar a regra para uma categoria-pai à espera de somar as filhas e ver os incidentes espalhados por subcategorias irmãs não se agruparem. Nas regras atuais isto resolve-se no operador: use "sob" para incluir as subcategorias; com "é", só a categoria escolhida conta. O mesmo vale para a localização.

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, filiais 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 mínimo 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 (o botão Testar existe para isso), confiança depois.

Compatibilidade

• GLPI: 11
• Plano: módulo licenciado
• Plugin: NexTool 6.24.1 ou superior (a versão pública atual cumpre)

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.

Revisto pela equipa NexTool Solutions.