Daily Archives: 28/04/2017

L’Ordine di lavoro nella gestione informatizzata della Manutenzione – parte 2

Published by:

La Richiesta/Ordine di Lavoro

Dopo aver realizzato il sistema di riferimento che ci permetterà di emettere ed elaborare la richiesta in questione, entriamo nel vivo della medesima. Segnaliamo innanzitutto che alcuni SW usano l’espressione RdL altri l’espressione OdL, altri entrambe, con significati sequenziali. Vediamo le definizioni UNI, che tengono conto ovviamente di tutti i possibili scenari.

UNI 10147.12.8 – 2003 Richiesta di Lavoro (RdL) : istruzione* con la quale si richiede l’intervento di manutenzione che deve essere fatto.

UNI 10147.12.5 – 2003 Ordine di Lavoro (OdL): istruzione* che attiva l’intervento di manutenzione a seguito di una richiesta di lavoro.

Istruzione*: può essere un documento cartaceo, una richiesta fatta attraverso supporti elettronici oppure richiesta verbale.

Di seguito gli scenari di emissione più diffusi:

  • RdL seguita da OdL. Si utilizza preferenzialmente questa modalità quando la richiesta di lavoro deve essere autorizzata per diventare esecutiva. Tipico ad esempio della manutenzione in regime di Global Service (completamente terziarizzata) o di Service più o meno spinto. Vi sono comunque SW che tracciano d’ufficio coi due passaggi la presa in carico della RdL. La chiusura dell’attività a lavoro eseguito richiede poi i due passaggi a ritroso.
  • Emissione della sola RdL. La tracciatura della presa in carico avviene definendo degli “stati di avanzamento” corrispondenti alle varie fasi di esecuzione del lavoro. E’ il sistema più utilizzato anche perché esiste comunque la possibiltà di inserire la fase di autorizzazione, ma gestione e chiusura sono più snelli.
  • Emissione del solo OdL, che coincide con la RdL di cui sopra. E’ solo una questione di terminologia. Noi sconsigliamo questo scambio di acronimi, in quanto UNI dà due definizioni distinte dei medesimi, che non dovrebbero quindi essere usati l’uno per l’altro. Tuttavia UNI non è cogente.

Chi scrive raccomanda di far riferimento al secondo scenario; questo sia per semplicità sia perché in ogni caso il primo passo per qualificare il “fabbisogno di manutenzione” resta sempre la RdL. Sottolineiamo “primo passo”, perché tutta la filiera del fabbisogno (quantificazione economica e temporale, problematiche e consuntivazione finale) è correlata univocamente alla RdL.

Come emettere la RdL

E’ quanto mai consigliato procedere per gradi o, meglio, per affinamenti successivi. Si raccomanda allo scopo di sviluppare l’Equipment Tree su Aree-Pilota prima di eseguire la mappatura di tutte le Unità Produttive. Le Aree Pilota devono essere rappresentative delle fasi del Processo, in modo da poter “clonare” il più possibile le esperienze fatte sulle medesime. Analoga fase sperimentale è raccomandabile anche per la messa a punto della “maschera” di emissione della RdL, che sarà testata ovviamente sulle Aree-Pilota di cui sopra. Per esperienza di chi scrive, il metodo più semplice consiste nell’utilizzare allo scopo un foglio Excel opportunamente organizzato, nonchè strutturato in modo da poter essere importato con facilità dai SW commerciali “definitivi” più diffusi. Aggiungiamo che la fase sperimentale su Excel di Equipment Tree e maschera di emissione RdL è particolarmente utile per una scelta più consapevole del SW definitivo stesso.

La Figura 2 riporta un’impostazione elaborata dallo scrivente sulla base di esperienze dirette e generalmente utilizzabile in qualsiasi settore merceologico. Se i dati immessi sono completi e veritieri, l’uso dei “filtri” di Excel permette di effettuare queries già notevolmente significative, specie per l’analisi dei dati di fermo e guasto in seguito a interventi di Manutenzione Correttiva.

Precisiamo inoltre che alla configurazione step by step dell’RdL partecipano sia il richiedente che l’esecutore, immettendo ciascuno i dati di propria competenza. Le informazioni dovranno essere congruenti. Pertanto la supervisione “educativa” e formativa da parte dell’Ingegneria di Manutenzione (IdM) non dovrà mai mancare e non solo nella fase sperimentale. Se la supervisione non è costante e collaborativa il processo di “data collection” si deteriora rapidamente, con buona pace del “completo e veritiero” sopra auspicato.

f2Figura 2

Contenuti delle colonne

N°RdL: è il numero progressivo della Richiesta di Lavoro. Il SW definitivo effettuerà la numerazione in automatico.

Codice posizione: è il codice di posizione riportato sull’Equipment Tree. Chi emette la RdL deve avere sempre a portata di mano l’Equipment Tree stesso. L’ideale sarà confezionare un documento Excel a più fogli, in modo da poter “chiamare” l’Equipment Tree in tempo reale, copiare il codice di posizione e incollarlo nella colonna in oggetto. E’ importante che il codice sia quello del livello di dettaglio più “spinto” disponibile sull’Equipment Tree. Se non lo fosse, la supervisione da parte di IdM se ne accorgerà e si cercherà di approfondire e correggere col Richiedente. Ciò contribuirà alla sua formazione, dandogli la percezione sia di non essere abbandonato sia del fatto che deve pensare con attenzione all’oggetto di manutenzione per cui chiede l’intervento.

Data evento: se la politica di manutenzione relativa alla riga che si sta compilando è la Correttiva (a guasto), la data coincide con la data di emissione della RdL. Se invece la RdL riguarda un’attività programmata, la data può essere diversa. Deciderà il Gruppo di Lavoro operante sull’Area-Pilota. A regime la data sarà immessa in automatico per i lavori non programmati, mentre per i PMP (Piani di Manutenzione Programmata) sarà l’Ingegneria di Manutenzione a definire ed immettere gli scadenziari. Ne tratteremo sul prossimo numero.

Richiedente: è il nominativo o il riferimento univoco (es. matricola) di chi richiede il lavoro. Può essere un appartenente a qualsiasi Funzione aziendale, purchè abilitato. Salvo emergenze palesi, non è pensabile fermare un manutentore “che passava di lì” e chiedergli di intervenire. Anche il pronto intervento deve essere richiesto tramite RdL, proprio perchè lo scopo ultimo del “Progetto Manutenzione” è segnatamente quello di spostare risorse dalle attività non programmate verso attività programmate. Ogni informazione sui fabbisogni non programmati è quindi preziosa per analizzarla e ridurli al minimo, sempre ovviamente in ottica di economicità.

Descrizione Intervento: è l’unico campo libero per tutte le politiche di manutenzione. Chi effettua li lavoro immette le informazioni che ritiene più utili, comprese le cause del guasto (se si tratta di manutenzione Correttiva) e se ritiene di immetterle. Si noterà che manca una colonna specifica, con le causali codificate e il relativo campo obbligato. La mancanza è voluta, in quanto l’esperienza di chi scrive dà per preferibile analizzare le cause di guasto in sede opportuna e, in fase di RdL, concentrarsi su altre informazioni che è bene cogliere “a caldo”. In questa fase, sempre per esperienza in campo, è molto più importante e ricco di contenuto informativo cogliere il componente elementare da cui il guasto ha avuto origine, come vedremo commentando i contenuti delle colonne “Codice Componente” e “Descrizione Componente”.

Esecutore: è il nominativo o il riferimento univoco (es. matricola, codice Fornitore etc.) di chi esegue il lavoro. E’ importante poter selezionare le attività svolte da personale interno, sia di manutenzione che di produzione (in sede di manutenzione autonoma o Automanutenzione) e le attività invece terziarizzate. Chiaramente il foglio Excel permetterà un dettaglio limitato, mentre il SW definitivo consentirà di avere una visione completa delle risorse necessarie per l’esecuzione del lavoro richiesto. Un buon SW permetterà anche di verificare eventuali scostamenti tra quanto preventivato e quanto consuntivato, di fare confronti tra fornitori, ricerche etc.

Politica di Manutenzione: Si raccomanda di creare una tendina con voci precostituite, in modo da agevolare sia il richiedente sia chi elaborerà le informazioni. Le voci raccomandate, almeno in questa fase, sono:

Manutenzione Correttiva; Manutenzione Preventiva Ciclica; Manutenzione Predittiva; Manutenzione Migliorativa, Assistenza all’Esercizio.

Per le definizioni, si rimanda alle Norme UNI. L’Assistenza all’Esercizio, a rigor di termini, non è una Politica di Manutenzione. Tuttavia talvolta è necessario, opportuno, conveniente etc. che la Manutenzione affianchi l’Esercizio per i più disparati motivi. A titolo esemplificativo e non esaustivo: attrezzaggi, pulizie tecniche, fermate/riavviamenti, start-up di nuovi impianti etc. Un caso interessante è la supplenza in manuale di perdita di automazione. Vedasi a tal proposito più avanti, quando si trattano gli “Effetti sul Processo”. L’impiego di risorse manutentive per necessità produttive deve essere comunque mappato, sia perché spesso segnale di una situazione anomala sia in quanto non sarebbe corretto scaricarne i costi sul già risicato budget della manutenzione.

Codice Componente e Descrizione Componente: come anticipato in Figura 1 (riquadro in rosso sopra l’ultima colonna di destra), invece di appesantire l’ET spingendolo a gradi di dettaglio onerosi e di difficile lettura da parte degli operatori, si raccomanda l’utilizzo di  “Flags” con liste codificate di “componenti elementari”, da utilizzarsi per selezionare ed immettere i componenti elementari (codice e descrizione) a corredo delle RdL relative alla Manutenzione Correttiva e non solo. Questo comporta numerosi vantaggi:

  • Si arriva a un dettaglio molto spinto senza appesantire l’Equipment Tree
  • Ogni “Flag” è valido per tutta l’Azienda: il medesimo componente elementare, ad esempio un fusibile, può essere operativo dovunque. ATTENZIONE: inserire o rimuovere un elemento dovrà essere di esclusiva competenza del System Administrator, supportato dall’ingegneria di Manutenzione, in modo da garantire la costante congruenza dei codici. I componenti saranno sempre descritti in ordine alfabetico, i codici non saranno necessariamente in progressione, se non alla prima stesura.
  • Si fornisce lo spunto di partenza per un’analisi del guasto rigorosa (vedere la voce “Descrizione Intervento” sopra commentata)
  • Si può creare un link con la Gestione Ricambi ( ovviamente a regime, col SW definitivo)
  • Si possono selezionare facilmente i componenti più critici

Ora inizio, Ora fine e Durata intervento: si tratta di informazioni quanto mai delicate, difficili da inquadrare e molto spesso anche da ottenere. Specialmente nel dominio della Manutenzione Correttiva (a guasto), quantificare i tempi effettivi di indisponibilità è per lo meno laborioso. Per contro, il pay back del costo delle possibili contromisure al guasto stesso è mediamente di gran lunga più coperto dal valore delle perdite di produzione (in quantità e/o qualità) che dal costo dell’intervento manutentivo vero e proprio. L’Ingegneria di Manutenzione ha necessità di conoscere quanto tempo trascorre dalla percezione dell’anomalia al ritorno alle condizioni produttive standard. Tale tempo complessivo misura la effettiva reattività del sistema ed è costituito dalla sommatoria di una serie di tempi, la cui analisi dettagliata è altrettanto importante ma sarà effettuata in sede opportuna.

Ore uomo impiegate: è un’informazione utile qualunque sia la Politica di Manutenzione attivata dalla RdL; permette di quantificare le risorse umane necessarie all’esecuzione del lavoro. Ovviamente il dato coincide col tempo di intervento solo se questo sarà eseguito da una sola persona. Se ho un fermo macchina di un’ora e sono intervenute più persone i due dati saranno diversi.

Effetto sul Processo: è uno dei dati più importanti per l’Ingegneria di Manutenzione, specie se la RdL è una richiesta di Manutenzione Correttiva. Anche qui, come nel caso della “Politica di Manutenzione”, si raccomanda di creare una tendina con voci precostituite, in modo da agevolare sia il richiedente sia chi elaborerà le informazioni. Le voci raccomandate, almeno in questa fase sono: Nessun effetto; perdita di velocità; perdita di qualità; fermo macchina/impianto; perdita di automazione; ambiente; sicurezza.

Osservazioni sulle due voci meno ovvie.

  • Nessun effetto. Se il fabbisogno di manutenzione non ha avuto effetti sul processo (ad esempio la fermata di una pompa con pompa di riserva, l’avaria di una scheda elettronica con back-up caldo etc), l’evento può comunque essere un sintomo di “disagio” e deve essere tracciato in quanto si è comunque trattato di un guasto.
  • Perdita di Automazione: è a volte possibile sopperire “in manuale” ad avarie, più frequentemente elettro-strumentali, che comportano perdita di automazione. Ad esempio: loop strumentali per trasferimento liquidi e robot “pick & place nel packaging. Con un po’ di buona volontà e per brevi periodi, in determinati casi è possibile sopperire. Come accennato quando si è trattato delle “Politiche di Manutenzione” si può ricorrere temporaneamente al contributo operativo anche da parte dei manutentori per evitare il fermo impianto. Sarebbe perciò una perdita di informazione pesante attribuire al guasto il “nessun effetto”.