NexTool Solutions

La gestione dei problemi è ciò che separa un'operatività che spegne lo stesso incendio ogni settimana da una che lo elimina alla radice. Nella gestione di ambienti GLPI di clienti, lo schema che vediamo più spesso non è la mancanza di processo, è il problema aperto, aggirato e marcato come Risolto lo stesso giorno - chiudendo il ciclo prima ancora che la causa radice sia documentata. Questa guida mostra dove vive ogni dato del problema in GLPI, come classificare senza inventare un campo che non esiste, e le trappole che fanno perdere un'indagine.

Incidente vs problema: la differenza è nel dato, non solo nel discorso

La confusione classica dell'ITSM è credere che "l'incidente diventi un problema". In GLPI non condividono nemmeno la tabella: l'incidente vive in glpi_tickets, il problema in glpi_problems, ciascuno con la propria macchina a stati. Sono oggetti distinti con obiettivi opposti:

• Incidente: ripristinare il servizio il più in fretta possibile. È curativo e ha uno SLA di risoluzione.
• Problema: trovare ed eliminare la causa radice affinché l'incidente non torni. È preventivo e va a un altro ritmo.

Esempio dal campo: il server di posta cade ogni lunedì. Ogni caduta è un incidente risolto riavviando il servizio. L'indagine che scopre che il backup settimanale esaurisce la memoria e fa cadere il servizio è il problema. Chiudere gli incidenti senza aprire il problema garantisce che il lunedì successivo porti lo stesso ticket.

La sezione Analisi: dove vive davvero la causa radice

Ciò che distingue il modulo del problema da quello di un ticket comune è la sezione Analisi, che scrive in tre colonne di testo dedicate di glpi_problems (esposte come opzioni di ricerca 60, 61 e 62):

• impactcontent - Impatti: ciò che il problema colpisce finché non è risolto.
• causecontent - Cause: qui vive la causa radice. È il campo più importante dell'intero processo.
• symptomcontent - Sintomi: come il problema si manifesta a chi apre un incidente.

La trappola dal campo più comune che incontriamo: la sezione Analisi è ripiegata per impostazione predefinita nel modulo. Il tecnico compila titolo e descrizione, registra la soluzione temporanea nella timeline e non apre mai la sezione - così causecontent resta vuoto. Il risultato: sei mesi dopo, nessuno sa perché quel problema è stato aperto né cosa è stato scoperto. Una causa radice che non arriva mai in causecontent non diventa conoscenza, diventa una diceria.

Incidente, problema o cambiamento: matrice decisionale

Prima di aprire qualsiasi registrazione, il team deve sapere cosa sta aprendo. Questa è la matrice che usiamo nel triage:

Nota che problema e cambiamento non competono: il flusso maturo è problema (trova la causa) - cambiamento (implementa la correzione) - base di conoscenza (documenta), tutto concatenato.

Collegare gli incidenti: la scheda Ticket e il tipo di collegamento

Ciò che dà corpo a un problema sono gli incidenti collegati ad esso. Nel modulo del problema, la scheda Ticket associa i ticket correlati, scrivendo nella tabella glpi_problems_tickets. Il dettaglio che quasi tutti ignorano: il collegamento ha un tipo. Collegare come "Collegato a" è diverso dal collegare come "Duplicato", e questo cambia la lettura dei report di ricorrenza. Standardizza il tipo di collegamento nel team, altrimenti il conteggio degli incidenti per problema perde senso - è stato uno dei primi aggiustamenti fatti in ambienti ereditati senza governance.

Il ciclo di vita e la trappola del "Risolto" troppo presto

Il problema ha la propria macchina a stati nella colonna status di glpi_problems, e non è uguale a quella del cambiamento. Gli stati che il problema usa davvero sono:

1. Nuovo (1) - registrato, non ancora indagato.
2. Accettato (7) - smistato e preso in carico dal team.
3. In corso / assegnato (2) e pianificato (3) - indagine in corso.
4. In attesa (4) - in attesa di un terzo, un fornitore o una finestra.
5. Sotto osservazione (8) - soluzione temporanea applicata, si monitora se la causa è stata davvero eliminata.
6. Risolto (5) e Chiuso (6) - causa eliminata e ciclo concluso.

Ecco l'errore comune che costa di più: applicare la soluzione temporanea e marcare il problema come Risolto lo stesso giorno. Risolto significa "la causa radice è sparita", ma una soluzione temporanea non elimina alcuna causa - nasconde solo il sintomo. In gestione abbiamo iniziato a usare lo stato Sotto osservazione (8) proprio per questo: la soluzione temporanea è in piedi, il problema resta vivo nel pannello, e lo spostiamo a Risolto solo dopo che la correzione definitiva è entrata ed è trascorso un periodo senza ricadute. Chiudere troppo presto è come cantare vittoria con l'incendio che cova ancora dietro il muro.

Soluzione temporanea, soluzione definitiva e il ponte verso il cambiamento

Un problema porta con sé due esiti che non vanno confusi:

• Soluzione temporanea (workaround): ripristina il servizio senza toccare la causa. Documentala nella timeline o come attività del problema (glpi_problemtasks) per l'uso immediato della prima linea.
• Soluzione definitiva: elimina la causa radice. Si registra nella scheda Soluzione, scrivendo in glpi_itilsolutions (con itemtype = 'Problem'), e spesso richiede un cambiamento per essere implementata.

Quando la correzione tocca l'infrastruttura, apri il cambiamento direttamente dal problema: il collegamento si scrive in glpi_changes_problems e mantiene la tracciabilità causa radice - azione correttiva. È questa linea che poi permette di dimostrare che il problema è stato davvero risolto e non solo chiuso.

Modello di notifica di chiusura del problema

In Configura > Notifiche, il modello dell'evento problema usa i tag di GLPI. Un corpo di chiusura che obbliga a registrare la causa radice riduce i problemi chiusi senza lezione appresa:

Oggetto: [Problema ##problem.id##] Chiuso - ##problem.title##

Ciao,

Il problema seguente è stato chiuso.

Titolo:      ##problem.title##
Categoria:   ##problem.category##
Stato:       ##problem.status##
Incidenti:   ##problem.numberoftickets##

Sintomi:
##problem.symptoms##

Causa radice:
##problem.causes##

Dettagli: ##problem.url##

I tag ##problem.causes## e ##problem.symptoms## attingono direttamente da causecontent e symptomcontent. Se la notifica di chiusura arriva con quei blocchi vuoti, è un segnale chiaro che il problema è stato chiuso senza causa radice documentata - e l'e-mail stessa diventa il revisore del processo.

Diagnostica: problemi con troppi incidenti e troppa poca causa

In gestione eseguiamo periodicamente una SELECT che incrocia ciò che conta di più: problemi ancora aperti con molti incidenti collegati ma senza causa radice compilata. È la coda del rilavoro imminente:

SELECT p.id,
       p.name AS problema,
       p.status,
       COUNT(pt.tickets_id) AS incidenti,
       IF(p.causecontent = '' OR p.causecontent IS NULL,
          'SENZA CAUSA RADICE', 'ok') AS causa
FROM glpi_problems p
LEFT JOIN glpi_problems_tickets pt ON pt.problems_id = p.id
WHERE p.is_deleted = 0
  AND p.status NOT IN (5, 6)          -- esclude Risolto e Chiuso
GROUP BY p.id
HAVING causa = 'SENZA CAUSA RADICE'
    OR incidenti >= 3
ORDER BY incidenti DESC;

Ogni riga con SENZA CAUSA RADICE e diversi incidenti è un problema che consuma sforzo di soluzione temporanea senza avanzare verso la soluzione. Trasformare questa query in un pannello settimanale cambia la conversazione nella riunione operativa: invece di "quanti ticket abbiamo chiuso", diventa "quali cause abbiamo eliminato".

Buone pratiche di gestione

• Non aspettare decine di incidenti: 3 occorrenze con lo stesso sintomo giustificano già un problema.
• Compila causecontent prima di chiudere, anche se la causa sembra ovvia; è ciò che diventa conoscenza.
• Usa Sotto osservazione mentre la soluzione temporanea gira; marca Risolto solo quando la causa è eliminata.
• Standardizza il tipo di collegamento degli incidenti affinché il conteggio della ricorrenza significhi qualcosa.
• Collega il problema al cambiamento (glpi_changes_problems) ogni volta che la correzione tocca l'infrastruttura.
• Rivedi i problemi aperti ogni settimana; un problema dimenticato è un incidente garantito in futuro.

Se l'operatività ha bisogno che i problemi ricorrenti vengano rilevati da soli - invece di dipendere da qualcuno che nota lo schema - il modulo Problem Flow individua gli incidenti ripetuti per categoria e frequenza e apre il problema con i ticket già collegati. Il supporto NexTool configura questo flusso sul GLPI che già usi, dal trigger di rilevamento al pannello delle cause eliminate.

Revisionato dal team NexTool Solutions.