NexTool Solutions

Un cambiamento ben gestito in GLPI non è quello con più campi compilati, è quello che riesci ad annullare alle 2 di notte quando fallisce. Questa guida percorre il ciclo di vita completo dei cambiamenti in GLPI: da quale sezione e colonna arriva ogni informazione, come modellare tipi di cambiamento che GLPI nativo non ha, e le insidie che abbiamo visto far saltare finestre di manutenzione negli ambienti che gestiamo per i clienti.

Il modello dati dietro un cambiamento

Ogni cambiamento vive nella tabella glpi_changes. Oltre ai campi ovvi (nome, contenuto, urgenza, impatto, priorità), ciò che distingue un cambiamento da un ticket comune sono le colonne di testo che GLPI espone nella sezione analisi e piani del modulo:

• impactcontent - analisi di impatto: cosa si rompe se va male.
• controlistcontent - lista di controllo: punti di verifica.
• rolloutplancontent - piano di implementazione (il core lo etichetta "Deployment plan"): il passo passo del rilascio.
• backoutplancontent - piano di ripristino/rollback (il core lo etichetta "Backup plan"): come tornare indietro.
• checklistcontent - checklist di validazione dopo l'implementazione.

Sapere che queste informazioni sono colonne separate, e non testo libero nella descrizione, è ciò che permette di verificare la governance direttamente nel database, come mostriamo più avanti.

"Tipo di cambiamento" in GLPI: il campo che non esiste

L'errore più comune di chi arriva da strumenti come ServiceNow è cercare un selettore "Tipo: Normale / Emergenza / Standard". Non esiste in GLPI nativo. Il cambiamento ha una categoria (itilcategories_id), urgenza, impatto e priorità, ma non un campo di tipo ITIL. La classificazione la modelli con categorie ITIL dedicate, che alimentano anche report e regole di business.

Il ciclo di vita, stato per stato

GLPI muove il cambiamento attraverso una macchina a stati propria, più ricca di quella del ticket. Lo stato corrente sta nella colonna status di glpi_changes:

1. Nuovo (1) - registrato in Assistenza > Cambiamenti, con descrizione, giustificazione, impatto e rischio.
2. Valutazione (4) - analisi di impatto e rischio; compilazione delle sezioni analisi e piani.
3. Approvazione (11) - giro di validazione con gli approvatori.
4. Accettato (12), Test (13), Qualifica (14) - pianificazione ed esecuzione delle attività (glpi_changetasks), ciascuna registrata nella timeline.
5. Risolto (5) - revisione dopo l'implementazione; conferma il successo e registra le lezioni apprese.
6. Chiuso (6) - documentazione finale e chiusura.

Ogni attività di cambiamento porta actiontime (tempo reale) e state (da fare/fatto), il che consente di confrontare lo sforzo pianificato con quello speso - dato che usiamo per calibrare le stime delle prossime finestre.

Approvazione: validazione nativa contro multilivello

L'approvazione nativa scrive in glpi_changevalidations (stato 2 = in attesa, 3 = approvato, 4 = rifiutato). Il dettaglio che frega quasi tutti: la validazione di GLPI è informativa, non è un cancello. Nulla impedisce di spostare il cambiamento da Approvazione a Test con la validazione ancora in attesa; GLPI non blocca la transizione. Se la tua governance richiede che nessuno implementi senza un'approvazione registrata, la sola validazione nativa non basta. È qui che entra Approval Flow, con approvazione multilivello e percorsi condizionali che bloccano davvero l'avanzamento.

Modello di notifica della richiesta di approvazione

In Configura > Notifiche, il modello dell'evento di validazione del cambiamento usa i tag di GLPI. Un corpo snello riduce i rimbalzi:

Oggetto: [Cambiamento ##change.id##] Approvazione richiesta - ##change.title##

Ciao,

Un cambiamento attende la tua approvazione.

Titolo:     ##change.title##
Categoria:  ##change.category##
Urgenza:    ##change.urgency##
Impatto:    ##change.impact##
Priorità:   ##change.priority##

Descrizione:
##change.content##

Approva o rifiuta su:
##change.url##

Tenere urgenza, impatto e priorità nel corpo evita che l'approvatore debba aprire il cambiamento solo per decidere. Questo riduce il tempo nello stato Approvazione, che è dove la maggior parte delle finestre accumula ritardo.

Diagnostica: cambiamenti senza piano di rollback

In gestione operativa, il campo che troviamo più spesso vuoto è proprio il più critico: backoutplancontent. La sezione piani arriva ripiegata nell'interfaccia, quindi il tecnico compila descrizione e attività ma mai il piano di ripristino, e il guasto emerge solo quando il cambiamento va male e nessuno sa tornare indietro. Eseguiamo questo SELECT ogni venerdì, prima della finestra del fine settimana:

SELECT c.id,
       c.name AS cambiamento,
       c.status,
       IF(c.backoutplancontent = '' OR c.backoutplancontent IS NULL,
          'SENZA ROLLBACK', 'ok') AS piano_ripristino
FROM glpi_changes c
WHERE c.is_deleted = 0
  AND c.status NOT IN (5, 6)          -- esclude Risolto e Chiuso
ORDER BY c.date DESC;

Qualsiasi riga con SENZA ROLLBACK è un cambiamento che non dovrebbe entrare in finestra. Lo trasformiamo in regola di business: senza piano di ripristino compilato, l'approvazione non passa.

Buone pratiche di gestione operativa

• Documenta backoutplancontent prima di chiedere l'approvazione, non dopo aver implementato.
• Collega il cambiamento al problema di origine (glpi_changes_problems) per mantenere la tracciabilità dalla causa radice all'azione correttiva.
• Crea modelli di cambiamento per quelli ricorrenti (standard) ed esentali dalla validazione.
• Pianifica fuori dagli orari di punta e registra l'actiontime reale per calibrare le stime.
• Chiudi il ciclo con la revisione dopo l'implementazione, anche quando tutto è andato bene; è ciò che diventa base di conoscenza.

Se l'operatività ha bisogno di un cancello di approvazione che blocchi davvero l'avanzamento e di una governance dei cambiamenti verificabile, il supporto NexTool configura questo flusso con il modulo Approval Flow sul GLPI che già usi.

Revisionato dal team NexTool Solutions.