Premesse
Un calendario di manutenzione generato automaticamente, di cui ho parlato nell’articolo precedente, è solo il punto di partenza. Prima che una singola occorrenza pianificata diventi un intervento vero e proprio, deve poter essere aggiustata liberamente – spostata per la disponibilità di un tecnico, accorpata a un’altra per ridurre i sopralluoghi, anticipata o posticipata in base a una priorità che cambia.
E una volta che l’intervento esiste davvero, deve poter essere seguito con precisione lungo il proprio percorso operativo, dalla richiesta alla chiusura formale. Sono due problemi distinti e complementari – pianificare prima, tracciare dopo – ed è su questi due, tenuti volutamente separati, che vale la pena entrare nel merito tecnico.
Perché il Gantt della manutenzione programmata è un efficace e necessario passaggio preventivo?
Un diagramma di Gantt applicato al calendario di manutenzione programmata condivide con quello del project management l’idea di base – occorrenze distribuite nel tempo, spostabili trascinando – ma opera per definizione su un orizzonte che precede la generazione dell’intervento vero e proprio. Finché una data pianificata resta una previsione, spostarla è un’operazione innocua e reversibile: è esattamente lo scopo del Gantt, aggiustare il calendario prima che diventi operativo.
Il punto in cui un’occorrenza smette di essere una previsione e diventa un intervento reale – assegnato, magari già in esecuzione – è un confine netto e precedente rispetto a qualunque rischio di “scompaginare” qualcosa: una volta oltrepassato quel confine, l’occorrenza semplicemente esce dal perimetro di ciò che il Gantt è chiamato ad ottimizzare.
Perché è utile organizzare il ciclo di vita di un intervento in fasi che raggruppano più stati, invece che un semplice “aperto/chiuso”?
Un sistema di stati limitato a “aperto/chiuso” nasconde informazioni operative preziose: non distingue ne sa analizzare i passaggi intermedi. Un modello più maturo raggruppa gli stati puntuali – che possono essere numerosi, per rispecchiare fedelmente le sfumature di un processo strutturato – in un numero contenuto di fasi macro comprensibili a colpo d’occhio: richiesta, approvazione, pianificazione, esecuzione, consuntivazione, chiusura.
È questo raggruppamento in fasi, non il conteggio degli stati puntuali sottostanti, a essere l’informazione che conta per chi deve avere una visione d’insieme del proprio carico di lavoro o del proprio patrimonio di interventi aperti, ed è ciò su cui si costruisce naturalmente una vista Kanban – colonne per fase, card per intervento.
Che ruolo ha una vista Kanban abbinata a un motore di regole di transizione configurabile, invece di un flusso di stati rigido cablato nel codice?
Una vista Kanban è un potente e comodo strumento di controllo perché il tecnico può facilmente trascinare una scheda intervento da una fase all’altra certo che il sistema si farà carico di verificare se quel passaggio ha senso nel processo dell’organizzazione: un intervento non può infatti saltare dalla richiesta iniziale direttamente alla chiusura, scavalcando approvazione ed esecuzione.
Coerentemente con il principio no-code che attraversa questa serie, la soluzione tecnicamente solida non è cablare queste regole nel codice dell’applicazione, ma affidarle a un motore di regole di transizione configurabile – un vero e proprio designer del flusso di lavoro, utilizzabile da un amministratore senza competenze di programmazione, che definisce quali passaggi tra stati sono leciti, quali richiedono un ruolo specifico per essere eseguiti, quali sono terminali.
Il Kanban diviene quindi l’interfaccia operativa con cui l’utente sposta le schede intervento; il motore di regole, dietro le quinte, decide se quel movimento è effettivamente permesso, e ogni organizzazione può adattare le proprie regole di processo senza dover richiedere una modifica al fornitore del software.
Che impatto complessivo ha questa combinazione di pianificazione preventiva e tracciabilità degli stati per chi vive il sistema ogni giorno?
Un proprietario che deve valutare oggettivamente le prestazioni di un fornitore in appalto trova, in stati granulari e finestre temporali ben definite per ogni transizione, i dati necessari a misurare tempi di risposta e di esecuzione senza doverli ricostruire a posteriori. Un building manager guadagna la possibilità di lavorare sulla pianificazione del calendario di manutenzione programmata con serenità, sapendo che il Gantt agisce solo su ciò che è ancora previsione, e di seguire con la stessa vista Kanban la programmazione e assegnazione degli interventi a guasto.
Il manutentore interno può fidarsi dello stato di un intervento come fonte di verifica sul proprio carico di lavoro, senza integrare mentalmente informazioni sparse. La ditta esterna o il global service, infine, trae dallo stesso meccanismo una rendicontazione periodica generata automaticamente dagli stati tracciati, invece di doverla ricostruire con un lavoro amministrativo separato da quello operativo.
Conclusioni
Separare con chiarezza la fase di pianificazione preventiva – un Gantt che agisce solo su ciò che non è ancora diventato un intervento reale – dalla fase di tracciamento dello stato una volta che l’intervento esiste, con fasi macro leggibili a colpo d’occhio e un motore di regole di transizione configurabile invece che cablato nel codice, è ciò che rende lo strumento di manutenzione del Software FM veramente affidabile senza irrigidirlo in un processo predefinito valido per tutte le organizzazioni allo stesso modo.
Nel prossimo articolo scendiamo ancora più nel concreto, con la manutenzione raccontata dal punto di vista del tecnico sul campo: checklist, firma e fotografie.
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui