Incidentes que se repetem são o sintoma de um problema que ninguém abriu ainda. No GLPI, perceber que dez chamados 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 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, 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 é 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 os chamados já solucionados e fechados e detecta incidentes recorrentes com regras no padrão do GLPI: categoria, localização, item associado, tipo de solução, prioridade, origem, grupos, solicitante e texto do título, da descrição ou da solução. Quando o mínimo de chamados da regra é atingido no período, um Problema ITIL é aberto no GLPI com os chamados que o originaram já vinculados.
- Gatilhos duplos - a avaliação roda sempre que um chamado é solucionado ou fechado e também pela tarefa automática do GLPI, a cada 6 horas por padrão, garantindo cobertura mesmo em picos de volume.
- Regras no padrão do GLPI - cada regra define os critérios, com os mesmos operadores das regras nativas (inclusive "sob", para subcategorias e sublocalizações), o mínimo de chamados no período, como agrupar (item, local, categoria, grupo técnico, solicitante ou setor), o mínimo de solicitantes 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 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 solicitantes 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, login, backup, segurança e certificado digital; mesma categoria; soluções de contorno recorrentes; e todo incidente crítico. Eles chegam desligados: você ativa só o que fizer sentido no seu ambiente.
- Soluções de contorno recorrentes - um dos modelos lê o texto da solução dos chamados: quando a mesma solução de contorno se repete, ela vira Problema, o "candidato a erro conhecido" da ITIL.
- Botão Testar - simula a regra nos chamados do período sem criar nada: mostra cada grupo, quantos chamados e solicitantes ele somou contra o mínimo e a prévia do Problema que seria aberto.
- Escopo alinhado à ITIL - os 27 modelos prontos contam só incidentes, como recomenda a ITIL; numa regra sua, o tipo do chamado é um critério que você escolhe.
- Rastreabilidade completa - a aba Logs registra, para cada detecção, a regra, o Problema gerado, o grupo e os chamados que o originaram.
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;O módulo faz esse trabalho sozinho, a cada avaliação e para cada regra, e não só por categoria e entidade: vale qualquer combinação de critérios (local, item associado, solicitante, texto da solução e os demais), com a contagem separada pelo agrupamento que você escolher e sem depender de alguém lembrar de rodar o relatório.
Recurso do módulo x comportamento nativo
| Etapa da gestão de problemas | GLPI nativo | Com o Problem Flow |
|---|---|---|
| Detectar recorrência | Manual: alguém precisa olhar relatórios e dashboards | Automática por regra, com qualquer combinação de critérios, ao solucionar ou fechar o chamado e pela tarefa automática |
| Calibrar antes de automatizar | Não existe: só se vê o resultado depois | Botão Testar simula a regra nos chamados do período sem criar nada |
| Abrir o Problema ITIL | Manual: o técnico cria e vincula os incidentes | Aberto ao atingir o mínimo, com os chamados vinculados e os campos definidos pelas ações da regra |
| Escopo da análise | Qualquer tipo de chamado, sem critério | O tipo do chamado é um critério da regra; os 27 modelos prontos contam só incidentes |
| Evitar Problemas repetidos | Depende de alguém procurar antes de abrir | Intervalo mínimo entre Problemas e chamados já vinculados ignorados |
| Rastreabilidade da decisão | Depende de anotação manual | Aba Logs com a regra, o grupo, os chamados e o Problema gerado |
| Evidência de maturidade ITSM | Difícil de comprovar | Trilha registrada de que o processo está ativo |
Como ativar
- Com o plugin NexTool instalado no GLPI 11, acesse NexTool > Módulos e ative o Problem Flow.
- Na aba Regras, escolha um dos 27 modelos prontos (eles chegam inativos) ou crie a sua regra.
- Clique em Testar: a simulação roda nos chamados do período e não cria nada.
- Com o resultado calibrado, ative a regra.
- Acompanhe a aba Logs para ver qual regra abriu cada Problema, para qual grupo e com quais chamados.
O que aprendemos na sustentação
Na sustentação de operações ITIL, o Problem Flow acerta ou erra pela calibragem do mínimo de chamados, não pela tecnologia. Mínimo 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 e passar pelo botão Testar antes de ativar: a simulação mostra, sobre os seus próprios chamados, cada grupo que a regra formaria, quantos chamados e solicitantes somou contra o mínimo e a prévia do Problema. O ajuste é feito ali, sem criar nada, em vez de esperar semanas de log. Dois detalhes que só aparecem operando: primeiro, contar chamados ainda abertos infla o número, porque o mesmo incidente reaberto aparece várias vezes - por isso a análise sobre solucionados e fechados é a correta. Segundo, o erro de campo mais comum era apontar a regra para uma categoria-pai esperando somar as filhas e ver os incidentes espalhados por subcategorias irmãs não se agruparem. Nas regras atuais isso se resolve no operador: use "sob" para incluir as subcategorias; com "é", só a categoria escolhida conta. O mesmo vale para 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 detecção manual de padrões é impraticável;
- Operações com múltiplas entidades, filiais 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 mínimo 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 (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 atende)
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.
Revisado pela equipe NexTool Solutions.
