NexTool Solutions

Un buon indicatore è quello di cui puoi indicare l'origine nel database. Questa guida mostra quali KPI del Service Desk vale davvero la pena seguire in GLPI, da quale tabella e colonna esce ciascun numero, quali intervalli usiamo come riferimento e le trappole che hanno già distorto decisioni negli ambienti che manteniamo per i clienti.

Prima del KPI, il modello dei dati

L'errore che vediamo più spesso rilevando un GLPI esistente è misurare "in superficie": confrontare date grezze invece di usare i campi che GLPI calcola già. Ogni ticket nella tabella glpi_tickets porta colonne statistiche pronte, le stesse che consuma il modulo Statistiche:

• takeintoaccount_delay_stat - secondi fino alla prima presa in carico (base del tempo di risposta / TTO).
• solve_delay_stat - secondi fino alla soluzione, già scontato il tempo in "In attesa" e regolato dal calendario lavorativo dell'entità (base del TMR / TTR).
• waiting_duration - totale dei secondi che il ticket è rimasto in attesa.
• time_to_resolve e time_to_own - le scadenze (deadline) dello SLA di risoluzione e di presa in carico.
• status - lo stato del ticket, che decide cosa entra o meno nel backlog.

Questo cambia tutto: il TMR calcolato come solvedate - date è diverso (e sempre maggiore) da ciò che restituisce solve_delay_stat, perché la sottrazione grezza somma notti, fine settimana e pause. Scegliere la colonna giusta è già metà del lavoro.

I KPI che contano e dove vive ciascuno

Non si tratta di avere dieci indicatori sul cruscotto; si tratta di avere quelli che generano azione. La matrice qui sotto lega ogni KPI alla sua fonte tecnica in GLPI e a un intervallo di riferimento onesto. Un intervallo, non un obiettivo universale: il numero giusto dipende dal contratto e dal tipo di operatività.

Estrarre i numeri direttamente dal database

Il modulo Statistiche (in Assistenza) risponde bene per una query occasionale e per esplorare per categoria, gruppo, tecnico e SLA. Ma non versiona lo storico mese per mese né incrocia più indicatori su una sola riga confrontabile. Quando serve la fotografia consolidata che entra nel report mensile dei clienti, andiamo al database con un utente in sola lettura:

-- KPI del mese corrente su una sola riga (usare un utente in sola lettura)
-- Origine: glpi_tickets, gli stessi campi che il modulo Statistiche legge
SELECT
    COUNT(*)                                                AS volume,
    SUM(status NOT IN (5,6))                                AS backlog,
    ROUND(AVG(NULLIF(takeintoaccount_delay_stat,0))/60, 1) AS tto_min,
    ROUND(AVG(NULLIF(solve_delay_stat,0))/3600, 1)         AS tmr_horas,
    ROUND(
      100 * SUM(solvedate IS NOT NULL AND solvedate <= time_to_resolve)
          / NULLIF(SUM(time_to_resolve IS NOT NULL AND solvedate IS NOT NULL), 0)
    , 1)                                                    AS sla_ttr_pct
FROM glpi_tickets
WHERE is_deleted = 0
  AND date >= DATE_FORMAT(CURDATE(), '%Y-%m-01');

La riapertura non ha una colonna propria: vive nello storico dei cambi di stato. In glpi_logs, una riapertura è il ticket uscito da Risolto (stato 5) e tornato in lavorazione. Il log memorizza il valore come "5 Risolto", quindi filtriamo per il prefisso numerico per non dipendere dalla lingua dell'installazione:

-- Riaperture del mese: ticket usciti da Risolto (5) e tornati
-- in lavorazione. In glpi_logs, id_search_option 12 = il campo stato
SELECT COUNT(DISTINCT items_id) AS reabertos
FROM glpi_logs
WHERE itemtype = 'Ticket'
  AND id_search_option = 12
  AND old_value LIKE '5 %'
  AND new_value REGEXP '^[123] '
  AND date_mod >= DATE_FORMAT(CURDATE(), '%Y-%m-01');

Automatizzare la raccolta mensile

Eseguire la query a mano ogni giorno 1 non scala. Pianifichiamo l'estrazione con il cron di sistema, puntando a un file di credenziali .cnf (chmod 600) per non lasciare mai la password sulla riga di comando, e conserviamo il CSV fuori da GLPI. Così nasce la serie temporale che il cruscotto nativo non conserva:

# /etc/cron.d/glpi-kpi  ->  giorno 1 alle 06:00, come www-data
# Credenziali nel file .cnf (chmod 600), mai sulla riga di comando
0 6 1 * * www-data /usr/bin/mysql --defaults-file=/etc/glpi/kpi-ro.cnf glpi \
  < /opt/glpi-kpi/kpi_mensal.sql >> /var/log/glpi-kpi/kpi-$(date +\%Y-\%m).csv 2>&1

Obiettivi: intervalli onesti, non numeri magici

• Rispetto dello SLA (TTR): sopra il 90-95% è sano per la maggior parte dei contratti. Un 100% costante di solito indica uno SLA troppo largo, non eccellenza.
• Riaperture: sotto il 5%. Oltre, indaga su una soluzione incompleta o su una chiusura affrettata per "rispettare" la scadenza.
• Risoluzione al primo livello: 70-80%. Sotto il 60% indica mancanza di formazione o cattiva categorizzazione; ben oltre il 90%, sospetta ticket complessi mal classificati.
• Soddisfazione (CSAT): sopra 4,0/5,0, ma sempre letta insieme al tasso di risposta al sondaggio.

Trappole che hanno già causato reperibilità

Nella manutenzione di ambienti dei clienti, la prima cosa che facciamo rilevando un GLPI già in esercizio è non fidarci del cruscotto nativo finché non validiamo la base. In un cliente con alto volume mensile di ticket, il TMR "ufficiale" sembrava ottimo finché non abbiamo notato che gran parte dei ticket aveva lo stesso utente come richiedente e tecnico già all'apertura: un'auto-assegnazione che azzera takeintoaccount_delay_stat e maschera il tempo di risposta reale. Abbiamo standardizzato l'estrazione via SQL pianificato proprio perché il modulo Statistiche non conserva storico mese per mese; senza serie temporale, confronti con la memoria, non con il dato.

Le trappole sul campo che più distorcono la lettura:

• Misurare il TMR per differenza di date. solvedate - date gonfia il numero: entrano notti, fine settimana e tempo in "In attesa". Usa solve_delay_stat, che GLPI regola già col calendario.
• Confondere Risolto con Chiuso. Se c'è una chiusura automatica dopo X giorni, misurare solo status = 6 nasconde i risolti in attesa di conferma. Il backlog deve escludere 5 e 6.
• Celebrare un TTO basso da auto-assegnazione. Un ticket aperto già assegnato azzera il tempo di risposta; il numero cala senza che l'operatività sia migliorata.
• Leggere la soddisfazione senza il tasso di risposta. Quando risponde solo chi è rimasto insoddisfatto, la media inganna. Incrocia satisfaction con quanti sondaggi sono stati effettivamente risposti.

Se il tuo GLPI mostra numeri di cui nessuno si fida, il problema è raramente GLPI: è la base e il modo di estrarre. La manutenzione GLPI di NexTool include la modellazione di questi indicatori e il report mensile consolidato che la direzione legge senza foglio di calcolo.

Questo contenuto è stato prodotto con l'ausilio dell'intelligenza artificiale e revisionato dal team Nextool Solutions.