Gli incidenti che continuano a ripresentarsi sono il sintomo di un problema che nessuno ha ancora aperto. In GLPI, accorgersi che dieci ticket Wi-Fi sono finiti nella stessa filiale in due settimane, o che lo stesso dispositivo è tornato in coda per la quarta volta, dipende da qualcuno che guardi il report giusto al momento giusto. Il modulo Problem Flow fa questa lettura da solo e crea il Problema ITIL automaticamente quando il pattern si conferma.
Il problema: il ponte tra incidente e problema è manuale
Chi gestisce ITIL sa che i Problemi sono la causa radice dietro gli incidenti ripetuti. GLPI ha l'itemtype Problema e permette di collegarvi gli incidenti, ma non rileva la ricorrenza: quella parte è umana. Qualcuno deve accorgersi che diversi ticket condividono la stessa categoria, lo stesso luogo o lo stesso dispositivo, nella stessa finestra temporale - e solo allora creare il Problema e collegare gli incidenti.
Questo divario ha un costo. L'intervallo tra la comparsa del pattern e l'apertura del Problema si riempie di altri incidenti, altro rilavoro e altro carico in coda. Nelle operazioni ad alto volume, il pattern di solito passa inosservato finché l'impatto non è già grande - e allora la domanda del responsabile è sempre la stessa: "perché nessuno l'ha visto prima?".
Come funziona Problem Flow
Il modulo valuta i ticket già risolti e chiusi e rileva gli incidenti ricorrenti con regole nel formato di GLPI: categoria, luogo, elemento associato, tipo di soluzione, priorità, origine della richiesta, gruppi, richiedente e testo del titolo, della descrizione o della soluzione. Quando nel periodo si raggiunge il minimo di ticket della regola, in GLPI viene aperto un Problema ITIL con i ticket che lo hanno originato già collegati.
- Trigger doppi - la valutazione viene eseguita ogni volta che un ticket viene risolto o chiuso e anche tramite l'azione automatica di GLPI, ogni 6 ore per impostazione predefinita, garantendo copertura anche nei picchi di volume.
- Regole nel formato di GLPI - ogni regola definisce i criteri, con gli stessi operatori delle regole native (incluso "sotto", per sottocategorie e sottoluoghi), il minimo di ticket nel periodo, come raggruppare (elemento, luogo, categoria, gruppo tecnico, richiedente o reparto), il minimo di richiedenti distinti, l'intervallo minimo tra Problemi e come nasce il Problema (titolo, modello, categoria, urgenza, impatto, gruppo tecnico, tecnico, gruppo osservatore). Più regole coesistono per coprire scenari diversi.
- Un Problema per ogni causa comune - raggruppando per luogo, con un minimo di 5, cinque incidenti Wi-Fi nella filiale Centro e cinque nella filiale Nord aprono due Problemi, uno per filiale. Il minimo di richiedenti distinti evita che una sola persona faccia scattare l'allarme, e l'intervallo minimo impedisce Problemi ripetuti.
- 27 modelli pronti, inattivi - lo stesso dispositivo con guasti ripetuti; Wi-Fi, stampa, energia e telefonia nello stesso luogo; e-mail, VPN, accesso, backup, sicurezza e certificato digitale; stessa categoria; soluzioni temporanee ricorrenti; e ogni incidente critico. Arrivano disattivati: Lei attiva solo ciò che ha senso nel Suo ambiente.
- Soluzioni temporanee ricorrenti - uno dei modelli legge il testo della soluzione dei ticket: quando la stessa soluzione temporanea si ripete, diventa un Problema, il "candidato a errore noto" dell'ITIL.
- Pulsante Testa - simula la regola sui ticket del periodo senza creare nulla: mostra ogni gruppo, quanti ticket e richiedenti ha sommato rispetto al minimo e l'anteprima del Problema che verrebbe aperto.
- Ambito in linea con l'ITIL - i 27 modelli pronti contano solo gli incidenti, come raccomanda l'ITIL; in una regola Sua, il tipo di ticket è un criterio che sceglie Lei.
- Tracciabilità completa - per ogni rilevamento, la scheda Logs registra la regola, il Problema generato, il gruppo e i ticket che lo hanno originato.
Il pattern che il modulo automatizza
Per capire cosa fa Problem Flow, è utile vedere il rilevamento fatto a mano. La query seguente elenca, per categoria ed entità, gli incidenti risolti o chiusi negli ultimi 30 giorni ed evidenzia i gruppi con cinque o più occorrenze - proprio i candidati a diventare un Problema. La esegua su una replica di lettura o in una finestra di basso utilizzo:
-- Rilevamento MANUALE del pattern che Problem Flow automatizza:
-- incidenti risolti/chiusi negli ultimi 30 giorni, raggruppati per categoria ed entita.
-- I gruppi con 5+ occorrenze sono candidati a diventare un Problema ITIL.
SELECT c.completename AS categoria,
e.completename AS entita,
COUNT(*) AS occorrenze
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 = Risolto, 6 = Chiuso
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 occorrenze DESC;Il modulo fa questo lavoro da solo, a ogni valutazione e per ogni regola, e non solo per categoria ed entità: vale qualsiasi combinazione di criteri (luogo, elemento associato, richiedente, testo della soluzione e gli altri), con il conteggio separato secondo il raggruppamento che sceglie e senza dipendere da qualcuno che si ricordi di lanciare il report.
Funzione del modulo rispetto al comportamento nativo
| Fase della gestione dei problemi | GLPI nativo | Con Problem Flow |
|---|---|---|
| Rilevare la ricorrenza | Manuale: qualcuno deve controllare report e dashboard | Automatica per regola, con qualsiasi combinazione di criteri, alla risoluzione o chiusura del ticket e tramite l'azione automatica |
| Calibrare prima di automatizzare | Non esiste: il risultato si vede solo dopo | Il pulsante Testa simula la regola sui ticket del periodo senza creare nulla |
| Aprire il Problema ITIL | Manuale: il tecnico lo crea e collega gli incidenti | Aperto al raggiungimento del minimo, con i ticket collegati e i campi definiti dalle azioni della regola |
| Ambito dell'analisi | Qualsiasi tipo di ticket, senza criterio | Il tipo di ticket è un criterio della regola; i 27 modelli pronti contano solo gli incidenti |
| Evitare Problemi ripetuti | Dipende da qualcuno che cerchi prima di aprire | Intervallo minimo tra Problemi e ticket già collegati ignorati |
| Tracciabilità della decisione | Dipende da un'annotazione manuale | Scheda Logs con la regola, il gruppo, i ticket e il Problema generato |
| Evidenza di maturità ITSM | Difficile da provare | Traccia registrata che il processo è attivo |
Come attivarlo
- Con il plugin NexTool installato su GLPI 11, vada in NexTool > Moduli e attivi Problem Flow.
- Nella scheda Regole, scelga uno dei 27 modelli pronti (arrivano inattivi) o crei la Sua regola.
- Faccia clic su Testa: la simulazione viene eseguita sui ticket del periodo e non crea nulla.
- Con il risultato calibrato, attivi la regola.
- Segua la scheda Logs per vedere quale regola ha aperto ogni Problema, per quale gruppo e con quali ticket.
Cosa abbiamo imparato nella manutenzione
Nella manutenzione di operazioni ITIL, Problem Flow riesce o fallisce sulla calibrazione del minimo di ticket, non sulla tecnologia. Minimo troppo basso e il modulo genera un Problema per categoria a settimana, diventando rumore che nessuno gestisce; troppo alto e non scatta mai, e si torna al rilevamento manuale. Abbiamo standardizzato l'iniziare in modo conservativo e il passare dal pulsante Testa prima di attivare: la simulazione mostra, sui Suoi ticket, ogni gruppo che la regola formerebbe, quanti ticket e richiedenti ha sommato rispetto al minimo e l'anteprima del Problema. La regolazione si fa lì, senza creare nulla, invece di attendere settimane di log. Due dettagli che si vedono solo operando: primo, contare i ticket ancora aperti gonfia il numero, perché lo stesso incidente riaperto compare più volte - per questo l'analisi sui risolti e chiusi è quella corretta. Secondo, l'errore sul campo più comune era puntare la regola su una categoria padre aspettandosi che sommasse le figlie, e vedere poi gli incidenti sparsi su sottocategorie sorelle non raggrupparsi. Nelle regole attuali lo risolve l'operatore: usi "sotto" per includere le sottocategorie; con "è", conta solo la categoria scelta. Lo stesso vale per i luoghi.
A chi è rivolto (e quando non usarlo)
Problem Flow è rivolto alle operazioni che adottano formalmente ITIL e vogliono colmare il divario tra gestione degli incidenti e gestione dei problemi, in particolare:
- Ambienti ad alto volume, dove il rilevamento manuale dei pattern è impraticabile;
- Operazioni con più entità, filiali o team distribuiti;
- Responsabili che hanno bisogno di una prova tracciabile di maturità ITSM per l'audit.
Non ha senso nelle operazioni che non praticano ancora la gestione dei problemi o hanno un volume molto basso: il minimo sarà raramente raggiunto e il modulo resta inattivo. E mal calibrato, produce troppi Problemi che il team non riesce a gestire - l'effetto collaterale è una coda di Problemi abbandonati, peggio che non avere l'automazione. Prima la calibrazione (il pulsante Testa serve a questo), poi la fiducia.
Compatibilità
- GLPI: 11
- Piano: modulo con licenza
- Plugin: NexTool 6.24.1 o superiore (la versione pubblica attuale è sufficiente)
Problem Flow fa parte di NexTool, un plugin modulare per GLPI. Per implementare la gestione dei problemi ITIL con rilevamento automatico e tracciabile, parli con il team.
Revisionato dal team NexTool Solutions.
