NexTool Solutions

I processi IT raramente stanno in un solo passo. La diagnosi porta all'esecuzione, l'esecuzione porta alla validazione, e ogni fase ha senso solo dopo il risultato della precedente. In GLPI standard, ognuna di queste attività nasce dalla digitazione manuale del tecnico, il che rende impossibile la standardizzazione non appena il volume cresce. Il modulo SubTask Flow concatena queste fasi: quando il tecnico registra la soluzione di un'attività nella timeline, la successiva viene creata automaticamente in base a quella risposta.

Perché creare l'attività successiva a mano non scala

Molti flussi di gestione sono prevedibili: analizzare, eseguire, validare, comunicare. GLPI offre modelli di attività (TaskTemplates) per standardizzare il contenuto di ogni passo, ma non sa che un passo deve generare il successivo. Il risultato è noto: il tecnico apre il modello giusto, copia responsabile e scadenza, e crea l'attività seguente a mano. In un ambiente con decine di tecnici, questo produce tre problemi cronici: fasi dimenticate, dati divergenti tra ticket equivalenti e nessuna tracciabilità del "perché questa attività esiste". Quando un audit chiede se la validazione è stata fatta, la risposta dipende dalla disciplina individuale di ogni tecnico, non da un processo progettato.

Come SubTask Flow concatena le attività per soluzione

Il modulo crea relazioni gerarchiche tra TaskTemplates. Un modello padre punta a uno o più modelli figli, e ogni figlio può essere condizionato a una soluzione specifica. Quando il tecnico registra la soluzione nella timeline dell'attività padre (o, se il modello non ha condizioni, segna l'attività come "Fatto"), il modulo esegue tre passi:

1. Identifica i modelli figli collegati a quella soluzione;
2. Crea le TicketTasks figlie nella timeline dello stesso ticket;
3. Copia contenuto, categoria, durata e responsabile (tecnico e gruppo) definiti nel modello figlio.

La configurazione vive nel modello, non nel ticket. Regola il flusso una volta e vale per tutti i ticket che usano quel modello, senza toccare regole di business né automazioni esterne. È la differenza tra documentare un processo e far sì che il sistema lo esegua.

Configurazione passo dopo passo

1. Standardizzi l'elenco delle soluzioni nella configurazione del modulo (per esempio: "hardware", "software", "nessun difetto"). Lo tratti come un vocabolario chiuso, non come testo libero.
2. Apra il TaskTemplate padre e colleghi i modelli figli nella scheda di concatenamento.
3. Per ogni figlio, definisca quale soluzione lo attiva. Un figlio condizionale richiede che il modello padre abbia lo stato predefinito "Informazione".
4. Si assicuri che ogni modello figlio abbia gruppo o tecnico responsabile e durata compilati - è il campo che fa più male dopo.
5. Prima del rilascio in produzione, conviene provare su un ticket di collaudo: per ogni soluzione possibile si crea un'attività padre di prova, si registra la soluzione nella timeline e si verifica che il figlio giusto nasca con i dati corretti.

Rilevamento dei cicli

Un concatenamento senza freno diventa una trappola. Un modello A che genera B, che genera C, che torna ad A, ricreerebbe le stesse attività a ogni giro, senza che il flusso finisca mai. Quando si salva un nuovo collegamento, il modulo esegue una ricerca in profondità (DFS) sul grafo dei modelli. Se trova un ciclo, mostra un avviso con il percorso del loop, ma il collegamento resta salvato: spetta a chi configura il flusso rimuoverlo. Viene bloccato solo il collegamento di un modello a se stesso. Per questo vale la stessa disciplina di ogni automazione: mantenere le catene corte e leggibili facilita la diagnosi quando qualcosa esce dal copione.

Tracciabilità: la scheda dei registri

Un'automazione senza registro è una scatola nera. SubTask Flow mantiene uno storico delle esecuzioni con il ticket, l'attività padre, l'attività figlia generata, chi l'ha avviata, chi l'ha completata e i timestamp. In un audit, questo risponde alla domanda più frequente - "questa sotto-attività è stata creata da una persona o dal flusso, e a partire da quale attività?" - senza dipendere dalla memoria di nessuno. È anche il primo posto dove guardare quando un cliente segnala che "la fase è sparita": il registro mostra se il trigger si è attivato e a partire da quale attività.

Diagnostica: auditare il flusso in SQL

L'automazione silenziosa richiede un monitoraggio attivo. La query seguente elenca le sotto-attività ancora aperte nate senza responsabile definito, il sintomo classico di un modello figlio incompleto. La esegua su una replica di lettura o in una finestra di basso utilizzo:

-- Sotto-attivita aperte (state=1) senza tecnico ne gruppo responsabile.
-- Segnala un TaskTemplate figlio con users_id_tech/groups_id_tech vuoto.
SELECT t.id                       AS ticket,
       tt.id                      AS task_id,
       tmpl.name                  AS modello,
       tt.state,
       tt.users_id_tech,
       tt.groups_id_tech,
       tt.date_creation
FROM glpi_tickettasks tt
JOIN glpi_tickets t               ON t.id  = tt.tickets_id
LEFT JOIN glpi_tasktemplates tmpl ON tmpl.id = tt.tasktemplates_id
WHERE tt.state = 1
  AND tt.users_id_tech  = 0
  AND tt.groups_id_tech = 0
  AND t.is_deleted = 0
ORDER BY tt.date_creation DESC
LIMIT 200;

In GLPI, state = 1 è "Da fare" e state = 2 è "Fatto". Se questo elenco cresce ogni settimana, il problema non è il modulo: è un modello figlio pubblicato senza responsabile, che genera attività che nessuno vede in coda.

Quando usarlo (e quando no)

L'errore di campo più comune

Nella manutenzione di ambienti con molti tecnici, il problema che compare di più non è tecnico, è di modellazione. Qualcuno configura il figlio perché si attivi sulla soluzione "Hardware", ma l'opzione che il tecnico sceglie davvero a schermo è "hardware" in minuscolo - o "HW", in un ambiente che ha ereditato il vocabolario da un altro strumento. Il trigger non combacia, la sotto-attività non nasce, nessuno riceve un errore, e il passo di esecuzione sparisce semplicemente dal processo senza lasciare traccia visibile. La correzione che abbiamo standardizzato: trattare le stringhe di soluzione come vocabolario controllato, tutte in minuscolo, documentate in una mappatura unica, e rivedere i modelli figli ogni volta che qualcuno aggiunge una soluzione nuova. Il secondo errore ricorrente è il modello figlio senza responsabile: l'attività nasce orfana, si perde in mezzo alla timeline e riappare solo quando lo SLA è già scaduto. Per questo la query SQL qui sopra fa parte della checklist di manutenzione, non di un audit occasionale.

NexTool implementa e mantiene ambienti GLPI con automazioni come SubTask Flow progettate per l'operatività reale di ogni cliente. Parli con il nostro team per mappare e automatizzare il flusso di attività del Suo team.

Revisionato dal team NexTool Solutions.