Lo strumento informatico a supporto del “Progetto Manutenzione” è imprescindibile e costituisce condizione necessaria di successo. Necessaria, non anche sufficiente, in quanto si tratta come appena detto di uno strumento. Esso deve pertanto essere calato in un ambiente dotato di sufficiente cultura di Manutenzione e maturità aziendale. L’emissione della Richiesta di Lavoro è il momento chiave per cogliere e capitalizzare il prezioso contenuto informativo che scaturisce dall’insorgere alla consuntivazione di un evento manutentivo, programmato o non programmato.
Prima di affrontare l’argomento riteniamo utile cercar di chiarire in cosa consiste la gestione informatizzata della Manutenzione. Riferiamoci come sempre (quando è possibile), alla normativa UNI. La Norma è la 10584 – 1997 e la definizione è la UNI 10584.3.1 Essa recita:
Sistema Informativo di Manutenzione (SIM): complesso di norme, procedure e strumenti atti ad accogliere ed elaborare le informazioni necessarie per la gestione delle attività di manutenzione e per il monitoraggio dell’attività degli impianti.
La definizione è sintetica ma, come tutte le definizioni tecnico/scientifiche (perché di questo si tratta), ogni parola va pesata in valore assoluto. E’ vero che dal 1997 a oggi l’informatica ha compiuto tali passi che le prestazioni ottenibili da parte di un SW di normale caratura sono decisamente ordini di grandezza superiori a quelle ottenibili alla data della stesura della Norma stessa, ma i principi concettuali e di buona applicazione sono invariati. A dimostrazione, solo apparentemente paradossale, di quanto appena detto, è interessante notare che la Norma, nel definire il SIM, NON pone come un “must” la gestione informatizzata del medesimo. A pag. IV della Norma, punto 1 – SCOPO E CAMPO DI APPLICAZIONE – si legge infatti: la presente norma individua e descrive le peculiarità del sistema informativo di manutenzione (SIM) sotto il profilo logico, procedurale e organizzativo, prescindendo dal sistema di supporto, che può essere realizzato anche in forma cartacea [ ..omissis…].
In pratica, è fondamentale che ci sia una consolidata organizzazione della manutenzione, nel cui ambito le informazioni descrittive della “storia” dei beni manutenuti siano sistematicamente raccolte e organizzate in forma codificata, ripetitiva e agevolmente consultabile; ciò al fine di poter prendere decisioni, progettare contromisure, stabilire priorità etc etc su basi analitiche-oggettive.
Ciò chiarito, il “può” concesso da UNI al cartaceo indica una possibilità ormai solo teorica o al massimo propedeutica/sperimentale. UNI lo ha doverosamente puntualizzato per coprire tutti i possibili scenari, purchè ci siano comunque dati “intelligenti” da elaborare e interpretare.
Il SIM presuppone quindi scelte / decisioni organizzative, tecniche e gestionali che vengono, anzi, devono venire ben prima del sistema di supporto, ovvero prima dello strumento e indipendentemente dalle sue prestazioni. Pertanto, al di là dell’atteggiamento giustificatamente “asettico” da parte di UNI, lo strumento per rendere efficacemente operativo il SIM non può che essere informatico. Il mondo anglosassone usa l’acronimo CMMS, che sta per Computerized Maintenance Management System. Ancora una volta gli acronimi anglosassoni sono più incisivi: nello specifico il contenuto “vero” sta nei termini Management System
Così come la Cultura di Manutenzione è un di cui della padronanza del sistema produttivo definita “Maturità Aziendale”, analogamente il CMMS è collocabile come sottoassieme (strategico !) di un sistema gestionale più ampio, classificato come EAM (Enterprise Asset Management), che quasi sempre si avvale della sinergia di più SW ed ha come missione la gestione del Life Cycle o Ciclo di vita dei beni.
E’ interessante arrivare alla conclusioni su cos’è il CMMS proponendo anche una riflessione sull’acronimo francese, GMAO, ovvero Gestion de la Maintenance Avec l’ Ordinateur, dove (ovviamente) Ordinateur sta per Computer. L’espressione francese ha il grande pregio di sottolineare la natura “strumentale” dell’apparecchio, finalizzata ad ordinare i dati in modo idoneo all’uso che se ne vuole fare. Effettivamente, per quanto supportato in maniera anche formidabile dallo strumento, il momento della trasformazione delle informazioni in conoscenze e da conoscenze in decisioni, è esclusiva prerogativa dei professionisti della manutenzione.
Il fabbisogno di manutenzione: dove intervenire e come procedere.
Come anticipato in apertura del presente articolo, l’insorgere di un fabbisogno di manutenzione è già di per sé un’informazione preziosa, informazione a cui fanno seguito tutte le successive, quelle relative alle attività messe in atto per soddisfare detto fabbisogno. Il “fabbisogno” può essere sia di manutenzione Programmata che Correttiva (non programmata; a guasto). La Richiesta-Ordine di Lavoro a cui ci riferiremo nel presente articolo viene emessa nel dominio della Manutenzione Ordinaria (Budget “a spese”), in quanto le attività di Manutenzione Straordinaria (salvo casi molto specifici) sono di norma progetti su investimento e in ogni caso gestiti con Software specifici per i progetti.
Una corretta mappatura del percorso genera un corredo informativo che, se ben organizzato, permette di gestire analiticamente (su basi numeriche) tutta la filiera, nonchè di ricavare informazioni oggettive per supportare decisioni tecniche ed organizzative e verificarne i risultati.
La corretta gestione informatizzata della manutenzione si fonda dunque su due poli strategici: l’Equipment Tree, che deve permettere di individuare univocamente dove scaturisce il fabbisogno e la Richiesta / Ordine di Lavoro che, emessa all’insorgere di un fabbisogno di manutenzione e riferita univocamente all’oggetto di manutenzione, permette di qualificare e quantificare tutte le informazioni che descrivono l’intervento manutentivo. Il tutto in forma codificata, “interrogabile” da ogni angolazione e con modalità tali che i dati possano essere confrontabili nel tempo tra loro e con altri dello stesso settore merceologico (possibilità di benchmarking).
L’Equipment Tree
Prima di progettare la “maschera” di emissione della RdL/OdL è dunque indispensabile “insegnare” al CMMS come rispondere al primo quesito, il più istintivo, di chi emetterà e di chi processerà il segnale di fabbisogno. Il quesito è “DOVE” ovvero dove è necessario intervenire.
Definire “DOVE” in modo semplice, univoco, tracciabile e tracciato, correlabile ad altre famiglie tecniche in funzione di parametri specifici è la parte più delicata dell’implementazione del CMMS: non si può sbagliare, pena il trascinamento pressoché irreversibile di “peccati originali” pesantemente invalidanti dell’uso e delle prestazioni del CMMS e di difficile se non addirittura impossibile rimozione una volta strutturato il tutto in un certo modo.
Di solito questa fase è supportata da consulenza specialistica, ma NON in informatica (quasi sempre già ampiamente presente): serve consulenza specialistica in Ingegneria di Manutenzione. E’ pessima consuetudine infatti che i CMMS vengano implementati nella loro struttura generale ed a scopi prettamente amministrativi, rimandando a tempi successivi l’implementazione dei cosiddetti “Moduli Tecnici”.
L’implementazione del CMMS va fatta invece con priorità alle esigenze dei moduli tecnici. Se funziona la parte gestionale, al massimo si prende atto di una situazione (effetti delle disfunzioni). Se funziona anche la parte tecnica, oltre a prendere atto della situazione si ricavano le conoscenze per migliorarla (cause delle disfunzioni). Nessuno potrà mai ridurre i costi (senza fare danni anche maggiori), a meno che non ne conosca le origini effettive ed agisca – o meglio, sappia agire – solo su quelle.
Senza entrare nel dettaglio delle tecniche di realizzazione dell’Equipment Tree, precisiamo soltanto che l’Ingegneria di Manutenzione seguirà comunque una logica gerarchica del tipo Padre-Figli-Nipoti e fermerà la scomposizione ad albero (da cui il nome) al livello di dettaglio minimo indispensabile. Trattando della maschera di emissione RdL/OdL vedremo poi come mappare anche i componenti elementari senza appesantire l’anagrafica degli impianti.
Per chiarire meglio quanto sopra, riportiamo in Figura 1 l’Equipment Tree di un ipotetico carroponte da parco rottami (acciaieria) con benna-ragno ad azionamento oleodinamico (a spicchi). Il principio da seguire è la “riproduzione del processo che la macchina deve compiere, chiedendosi cosa deve funzionare correttamente e contemporaneamente affinchè il processo abbia luogo.
Relativamente al Carroponte, vediamo che il suo “processo” consiste nell’afferrare del rottame e spostarlo in uno spazio tridimensionale. Occorre quindi che funzionino i 4 sottoassiemi fondamentali posti al secondo livello, ciascuno preposto ad un tipo di spostamento. A propria volta, ogni sottoassieme può funzionare se funzionano le apparecchiature che lo compongono, poste al terzo livello rispetto al livello individuato come primo. Logicamente, se a livello aziendale si decide che il codice di primo livello sia quello dello Stabilimento, al secondo livello ci sarà l’Impianto, poi la linea ed infine la macchina. La codifica sarà sequenziale, in logica gerarchica, sicuramente recuperando i codici esistenti ma non perdendo la descrizine sintetica del processo.
La scomposizione può proseguire all’infinito o quasi, ma si sconsiglia vivamente di appesantire l’ET oltre il minimo indispensabile.
Figura 1. Esempio didattico di Equipment Tree