Sapere dove si trova è il primo passo per sapere dove andare. Questa guida mostra come valutare il livello di maturità ITSM della Sua operatività con segnali oggettivi estratti da GLPI stesso - senza dipendere dalla percezione - e come dare priorità ai prossimi passi della Sua evoluzione.
La maturità non si misura per opinione
La domanda "a che livello siamo?" riceve quasi sempre una risposta emotiva: chi spegne incendi ogni giorno giura di essere al livello 1, e il responsabile che ha approvato l'acquisto dello strumento giura di essere al livello 4. Entrambi sbagliano, perché misurano una sensazione, non un processo. La maturità ITSM è il grado di formalizzazione, automazione e ottimizzazione della gestione dei servizi, e lascia tracce misurabili nel database dello strumento. Prima di ingaggiare una consulenza o acquistare altri moduli, conviene estrarre quelle tracce.
Diagnosi oggettiva: chieda a GLPI stesso
Tre segnali separano bene un'operatività matura da una immatura: quanti ticket sono realmente categorizzati, quanti hanno uno SLA associato e quanto tempo impiegano a essere risolti. Esegua la query seguente direttamente sul database (sola lettura) sugli ultimi 90 giorni:
-- Segnali di maturita negli ultimi 90 giorni (GLPI 10/11)
SELECT
COUNT(*) AS totale_ticket,
ROUND(100 * SUM(itilcategories_id > 0) / COUNT(*), 1) AS pct_categorizzati,
ROUND(100 * SUM(slas_id_ttr > 0) / COUNT(*), 1) AS pct_con_sla_risoluzione,
ROUND(AVG(TIMESTAMPDIFF(HOUR, date, solvedate)), 1) AS ore_medie_per_risolvere
FROM glpi_tickets
WHERE date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
AND is_deleted = 0
AND solvedate IS NOT NULL;Lettura sul campo: sotto il 70% di ticket categorizzati, dimentichi la gestione dei problemi - non ha una base per raggruppare le ricorrenze. Sotto il 50% con uno SLA associato, i Suoi report di conformità misurano solo la frazione che ha una scadenza, non tutta l'operatività. E se la media di ore per risolvere oscilla molto da mese a mese, il processo è ancora ad-hoc anche se esiste uno strumento.
Matrice: livello x segnale in GLPI x azione
Usi la matrice per collocare il Suo livello in base a ciò che GLPI mostra oggi, non a ciò che vorrebbe mostrasse:
| Livello | Segnale osservabile in GLPI | Prossima azione tecnica | Metrica obiettivo |
|---|---|---|---|
| 1 - Ad-hoc | Nessuno strumento, o ticket senza categoria/SLA | Implementare GLPI, creare entità e profili | 100% dei ticket nello strumento |
| 2 - Ripetibile | Ticket aperti, ma domina la categoria "Altro" | Albero di categorie snello + SLA iniziale | >70% categorizzati |
| 3 - Definito | Categorie e SLA in uso; assegnazione manuale | Regole di business (assegnazione), base di conoscenza | SLA associato >90% |
| 4 - Gestito | Metriche raccolte; cron in CLI | Gestione dei problemi e dei cambiamenti, dashboard | SLA rispettato >90% |
| 5 - Ottimizzato | Decisione basata sul dato; automazione matura | Analisi di ricorrenza, integrazione con il business | Calo anno su anno della ricorrenza |
Il dettaglio di gestione operativa che falsa ogni metrica
Nella gestione operativa degli ambienti dei clienti, l'indicatore più ingannevole è lo "SLA rispettato" quando le azioni automatiche di GLPI girano in modalità GLPI (attivate dal browser) invece che in CLI. In quella modalità, il ricalcolo delle scadenze, le escalation e le notifiche avvengono solo quando qualcuno apre una pagina del sistema. Risultato: alle 3 di notte, con nessuno collegato, nessun ticket viene scalato, e il report del giorno dopo mostra uno SLA verde che non corrisponde alla realtà. L'errore comune è fidarsi della dashboard senza controllare, in Configurazione > Azioni automatiche, quale sia la modalità di esecuzione. La correzione è standardizzare tutto in CLI e pianificare il cron di sistema:
# /etc/cron.d/glpi - esegue le azioni automatiche ogni minuto
# Vale per GLPI 10 e 11 (front/cron.php e portabile; sul 11 evita di dipendere dalla console)
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php &>/dev/nullDopo il passaggio a CLI, in Azioni automatiche cambi la modalità di esecuzione di ogni attività critica (queuednotification, slaticket, closeticket) in CLI. Senza questo, può essere al livello 4 sulla carta e al livello 2 nella pratica.
La trappola dell'albero di categorie ereditato
Un altro inciampo ricorrente: salire di livello credendo che "avere molte categorie" sia un segno di maturità. È il contrario. Abbiamo preso in carico un ambiente che portava circa 400 categorie importate da un sistema legacy, annidate su cinque livelli. In pratica, gli operatori non trovavano la categoria giusta, sceglievano la prima che compariva e il campo diventava rumore. Abbiamo ricategorizzato lo storico degli ultimi mesi, ridotto l'albero a poco più di due dozzine di categorie che riflettevano ciò che il team gestisce davvero, e solo allora i report per causa hanno iniziato ad avere senso. La regola pratica che usiamo: se una categoria non riceve un ticket da 90 giorni, è candidata a sparire. Troppe categorie non misurano la maturità; ostacolano il triage e falsano qualsiasi analisi di ricorrenza.
Checklist di valutazione rapida
- Esiste uno strumento ITSM con tutti i ticket al suo interno? (sì = livello 2+)
- Più del 70% dei ticket è in una categoria specifica, non "Altro"? (sì = livello 3+)
- Lo SLA è associato e il cron gira in CLI validato? (sì = livello 3+)
- Le metriche vengono raccolte e riviste in una riunione fissa? (sì = livello 4+)
- Le decisioni nascono dal dato, non dalla percezione? (sì = livello 4+)
- Esiste una gestione dei problemi attiva che riduce la ricorrenza? (sì = livello 5)
Piano di evoluzione: un livello alla volta
Non cerchi di saltare le tappe - ogni livello si appoggia sul precedente. Se la diagnosi ha mostrato una categorizzazione bassa, il prossimo passo non è comprare l'IA; è ridurre l'albero delle categorie a ciò che il team usa davvero (in pratica, da 15 a 25 categorie coprono la maggior parte delle operatività di medie dimensioni) e addestrare il triage. Solo dopo che la categorizzazione si stabilizza la gestione dei problemi acquista senso, perché finalmente può raggruppare gli incidenti per causa. Se è al livello 1-2, cominci dall'implementazione di GLPI e dalla configurazione di base prima di qualsiasi automazione.
Nella nostra esperienza di gestione operativa, il guadagno di maturità più rapido non arriva da una nuova funzione, ma dal ripulire ciò che già esiste: cron in CLI, categorie snelle e uno SLA associato al 100% dei tipi di ticket. Questi tre aggiustamenti spostano un'operatività dal livello 2 al livello 3 in poche settimane, senza costi di licenza aggiuntivi.
Se vuole una diagnosi di maturità con questi indicatori estratti dal Suo stesso ambiente, NexTool valuta e mantiene GLPI per operatività B2B - dalla configurazione di base al livello ottimizzato.
Revisionato dal team NexTool Solutions.
