Los incidentes que se repiten son el síntoma de un problema que nadie ha abierto todavía. En GLPI, darse cuenta de que diez tickets de Wi-Fi cayeron en la misma sucursal en dos semanas, o de que el mismo equipo volvió a la cola por cuarta vez, depende de que alguien mire el informe correcto en el momento correcto. El módulo Problem Flow hace esa lectura por sí solo y crea el Problema ITIL automáticamente cuando el patrón se confirma.
El problema: el puente entre incidente y problema es manual
Quien opera ITIL sabe que los Problemas son la causa raíz detrás de los incidentes repetidos. GLPI tiene el itemtype Problema y permite vincular incidentes, pero no detecta la recurrencia: esa parte es humana. Alguien tiene que notar que varios tickets comparten la misma categoría, la misma ubicación o el mismo equipo, en la misma ventana de tiempo - y solo entonces crear el Problema y vincular los incidentes.
Esa brecha tiene un costo. El intervalo entre que el patrón aparece y que el Problema se abre se llena de más incidentes, más retrabajo y más carga en la cola. En operaciones de alto volumen, el patrón suele pasar desapercibido hasta que el impacto ya es grande - y entonces la pregunta del responsable es siempre la misma: "¿por qué nadie vio esto antes?".
Cómo funciona Problem Flow
El módulo evalúa los tickets ya resueltos y cerrados y detecta incidentes recurrentes con reglas en el formato de GLPI: categoría, ubicación, elemento asociado, tipo de solución, prioridad, origen, grupos, solicitante y texto del título, de la descripción o de la solución. Cuando se alcanza el mínimo de tickets de la regla en el período, se abre un Problema ITIL en GLPI con los tickets que lo originaron ya vinculados.
- Disparadores dobles - la evaluación se ejecuta cada vez que un ticket se resuelve o se cierra y también mediante la acción automática de GLPI, cada 6 horas por defecto, garantizando cobertura incluso en picos de volumen.
- Reglas en el formato de GLPI - cada regla define los criterios, con los mismos operadores de las reglas nativas (incluido "bajo", para subcategorías y sububicaciones), el mínimo de tickets en el período, cómo agrupar (elemento, ubicación, categoría, grupo técnico, solicitante o sector), el mínimo de solicitantes distintos, el intervalo mínimo entre Problemas y cómo nace el Problema (título, plantilla, categoría, urgencia, impacto, grupo técnico, técnico, grupo observador). Varias reglas coexisten para cubrir escenarios distintos.
- Un Problema por causa común - agrupando por ubicación, con un mínimo de 5, cinco incidentes de Wi-Fi en la sucursal Centro y cinco en la sucursal Norte abren dos Problemas, uno por sucursal. El mínimo de solicitantes distintos evita que una sola persona dispare la alarma, y el intervalo mínimo impide Problemas repetidos.
- 27 plantillas listas, inactivas - el mismo equipo con fallas repetidas; Wi-Fi, impresión, energía y telefonía en el mismo lugar; correo, VPN, inicio de sesión, backup, seguridad y certificado digital; misma categoría; soluciones alternativas recurrentes; y todo incidente crítico. Llegan desactivadas: activas solo lo que tenga sentido en tu entorno.
- Soluciones alternativas recurrentes - una de las plantillas lee el texto de la solución de los tickets: cuando la misma solución alternativa se repite, se convierte en Problema, el "candidato a error conocido" de ITIL.
- Botón Probar - simula la regla en los tickets del período sin crear nada: muestra cada grupo, cuántos tickets y solicitantes sumó frente al mínimo y la vista previa del Problema que se abriría.
- Alcance alineado con ITIL - las 27 plantillas listas cuentan solo incidentes, como recomienda ITIL; en una regla tuya, el tipo de ticket es un criterio que tú eliges.
- Trazabilidad completa - la pestaña Logs registra, para cada detección, la regla, el Problema generado, el grupo y los tickets que lo originaron.
El patrón que el módulo automatiza
Para entender qué hace Problem Flow, conviene ver la detección hecha a mano. La consulta siguiente lista, por categoría y entidad, los incidentes resueltos o cerrados en los últimos 30 días y destaca los grupos con cinco o más ocurrencias - justo los candidatos a convertirse en Problema. Ejecútala en una réplica de lectura o en una ventana de bajo uso:
-- Deteccion MANUAL del patron que Problem Flow automatiza:
-- incidentes resueltos/cerrados en los ultimos 30 dias, agrupados por categoria y entidad.
-- Los grupos con 5+ ocurrencias son candidatos a convertirse en un Problema ITIL.
SELECT c.completename AS categoria,
e.completename AS entidad,
COUNT(*) AS ocurrencias
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 = Resuelto, 6 = Cerrado
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 ocurrencias DESC;El módulo hace este trabajo por sí solo, en cada evaluación y para cada regla, y no solo por categoría y entidad: sirve cualquier combinación de criterios (ubicación, elemento asociado, solicitante, texto de la solución y los demás), con el conteo separado por el agrupamiento que elijas y sin depender de que alguien se acuerde de ejecutar el informe.
Función del módulo frente al comportamiento nativo
| Paso de la gestión de problemas | GLPI nativo | Con Problem Flow |
|---|---|---|
| Detectar recurrencia | Manual: alguien debe revisar informes y dashboards | Automática por regla, con cualquier combinación de criterios, al resolver o cerrar el ticket y mediante la acción automática |
| Calibrar antes de automatizar | No existe: el resultado solo se ve después | El botón Probar simula la regla en los tickets del período sin crear nada |
| Abrir el Problema ITIL | Manual: el técnico lo crea y vincula los incidentes | Abierto al alcanzar el mínimo, con los tickets vinculados y los campos definidos por las acciones de la regla |
| Alcance del análisis | Cualquier tipo de ticket, sin criterio | El tipo de ticket es un criterio de la regla; las 27 plantillas listas cuentan solo incidentes |
| Evitar Problemas repetidos | Depende de que alguien busque antes de abrir | Intervalo mínimo entre Problemas y tickets ya vinculados ignorados |
| Trazabilidad de la decisión | Depende de una anotación manual | Pestaña Logs con la regla, el grupo, los tickets y el Problema generado |
| Evidencia de madurez ITSM | Difícil de comprobar | Rastro registrado de que el proceso está activo |
Cómo activarlo
- Con el plugin NexTool instalado en GLPI 11, ve a NexTool > Módulos y activa Problem Flow.
- En la pestaña Reglas, elige una de las 27 plantillas listas (llegan inactivas) o crea tu propia regla.
- Haz clic en Probar: la simulación se ejecuta en los tickets del período y no crea nada.
- Con el resultado calibrado, activa la regla.
- Sigue la pestaña Logs para ver qué regla abrió cada Problema, para qué grupo y con qué tickets.
Lo que aprendimos en la sustentación
En la sustentación de operaciones ITIL, Problem Flow acierta o falla por la calibración del mínimo de tickets, no por la tecnología. Un mínimo demasiado bajo y el módulo genera un Problema por categoría por semana, convertido en ruido que nadie atiende; demasiado alto y nunca dispara, y vuelves a la detección manual. Estandarizamos empezar conservador y pasar por el botón Probar antes de activar: la simulación muestra, sobre tus propios tickets, cada grupo que la regla formaría, cuántos tickets y solicitantes sumó frente al mínimo y la vista previa del Problema. El ajuste se hace ahí, sin crear nada, en lugar de esperar semanas de log. Dos detalles que solo se ven operando: primero, contar tickets aún abiertos infla el número, porque el mismo incidente reabierto aparece varias veces - por eso el análisis sobre resueltos y cerrados es el correcto. Segundo, el error de campo más común era apuntar la regla a una categoría padre esperando sumar las hijas y ver que los incidentes dispersos por subcategorías hermanas no se agrupaban. En las reglas actuales esto se resuelve con el operador: usa "bajo" para incluir las subcategorías; con "es", solo cuenta la categoría elegida. Lo mismo vale para la ubicación.
Para quién es (y cuándo no usarlo)
Problem Flow es para operaciones que adoptan ITIL formalmente y quieren cerrar la brecha entre gestión de incidentes y gestión de problemas, en especial:
- Entornos de alto volumen, donde la detección manual de patrones es impracticable;
- Operaciones con múltiples entidades, sucursales o equipos distribuidos;
- Responsables que necesitan evidencia rastreable de madurez ITSM para auditoría.
No tiene sentido en operaciones que aún no practican gestión de problemas o tienen volumen muy bajo: el mínimo rara vez se alcanzará y el módulo queda ocioso. Y mal calibrado, produce demasiados Problemas que el equipo no puede atender - el efecto colateral es una cola de Problemas abandonados, peor que no tener la automatización. Primero la calibración (para eso está el botón Probar), después la confianza.
Compatibilidad
- GLPI: 11
- Plan: módulo con licencia
- Plugin: NexTool 6.24.1 o superior (la versión pública actual cumple)
Problem Flow forma parte de NexTool, un plugin modular para GLPI. Para implementar la gestión de problemas ITIL con detección automática y trazable, habla con el equipo.
Revisado por el equipo de NexTool Solutions.
