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: al completamento di un'attività, la successiva viene creata automaticamente in base alla soluzione scelta.

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 segna l'attività padre come "Fatto" e sceglie la soluzione, 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, tempo stimato e responsabile definiti nel modello figlio.

La configurazione vive nel modello, non nel ticket. Regoli 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. Standardizza l'elenco delle soluzioni nella configurazione del modulo (per esempio: "hardware", "software", "nessun difetto"). Trattalo come un vocabolario chiuso, non come testo libero.
2. Apri il TaskTemplate padre e collega i modelli figli nella scheda di concatenamento.
3. Per ogni figlio, definisci quale soluzione lo attiva.
4. Assicurati che ogni modello figlio abbia gruppo o tecnico responsabile e tempo stimato compilati - è il campo che fa più male dopo.
5. Prova su un ticket di collaudo prima del rilascio in produzione: completa l'attività padre, scegli ogni soluzione possibile e conferma che il figlio giusto nasce con i dati corretti.

Protezione dai cicli

Un concatenamento senza freno diventa una trappola. Un modello A che genera B, che genera C, che torna ad A, creerebbe attività all'infinito e bloccherebbe la timeline del ticket. Prima di accettare un nuovo collegamento, il modulo esegue una ricerca in profondità (DFS) sul grafo dei modelli. Se il collegamento chiude un ciclo, viene rifiutato con un messaggio esplicativo invece di lasciare che il problema esploda in produzione. 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 modello padre, il modello figlio generato, la soluzione scelta, il tecnico responsabile 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 decisione?" - 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 con quale soluzione.

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. Eseguila 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. Parla con il nostro team per mappare e automatizzare il flusso di attività del tuo team.

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