Visto l’enorme (…) successo dell’articolo sui KPI di un impianto di trattamento, affrontiamo un’altra generalizzazione.
L’intenzione è quello di vedere in modo più astratto delle situazioni che in azienda sembrano tutte diverse in modo da avere un approccio “top-down” (mondo IT) invece del “bottom-up” (mondo OT).
Qui il report con Google Looker e può essere interessante un esempio di analisi di un log di produzione.
Non sai come fare queste semplici cose ma vorresti farle? Scrivimi e vediamo che strada si può prendere!
Stato macchina
Immaginiamo una macchina qualsiasi che, a parte fare il suo lavoro, possa essere in tre stati:
- in lavoro (1)
- in pausa (0)
- in errore (2)
Questi tre stati sono di una ovvietà colossale e disponibili per ogni macchina. Quindi diamo per scontato di avere una serie di dati (timeseries) del tipo:
- data e ora
- stato macchina
Un esempio potrebbe essere quello in figura.
Con questi dati, in un qualsiasi servizio di analisi/visualizzazione dati si possono fare grafici e aggregazioni interessanti.
Non sempre, però, si riesce a rispondere alla domanda: “quante volte è andata in errore nella giornata?” Per rispondere a questa domanda, le singole righe in sequenza che riportano lo stato 2 (errore) devono essere considerate una sola.
Rielaborare i dati
Se non si ha altro a disposizione bisogna “processare” il log, che è la parte più difficile, e ricondurlo ad una situazione dove abbiamo:
- data e ora
- stato
- durata
A me non risulta che questa operazione sia ovvia da fare con i database (nemmeno con quelli timeseries) e/o con strumenti di visualizzazione. Ogni informazione è gradita.
Con un piccolo sforzo, peraltro, la macchina stessa potrebbe fornire questa informazione nativamente (non c’è motivo di analizzare il cambio di stato fuori dalla macchina visto che lo genera la macchina stessa… ma questa è una mia personale opinione).
Se riusciamo a ricondurci a questa sequenza di dati, ci troviamo con:
Da qui in poi tutto è in discesa. Il cruscotto che si vede qui sotto, realizzato in pochi minuti, permette di sapere:
- quante tempo la macchina è stata in errore
- quante volte è andata in errore nella giornata
- quanto mediamente resta in errore prima di ripartire
I punti 2 e 3 non sono solo uno sfizio statistico.
Sapere quante volte la macchina è andata in errore e ha richiesto l’intervento di un operatore è fondamentale: un fermo di due ore è diverso da 12 fermi da 10 minuti.
Sapere il tempo medio che la macchina rimane in errore è un altro dato fondamentale.
In caso di blocchi che sono connaturati al processo e che richiedono, ad esempio, 5 minuti per essere risolti, avere un fermo medio di 30 minuti significa che l’operatore non è sufficientemente disponibile.
Darei due declinazioni a questa ultima osservazione:
- c’è poco personale e quindi non si può migliorare il tempo di intervento
- il personale non viene avvisato del fermo e ci si affida al giro macchine per scoprirlo (non lo scriverei se non l’avessi visto)
Non solo errori
Chiaramente le valutazioni si possono estendere agli altri stati, non solo quelli di errore. Inoltre, ma entriamo nel mondo dell’OEE, si possono valutare i rapporti tra gli stati, integrati con le misure di qualità, di manutenzione, …
Conclusione
Queste generalizzazioni sembrano così semplici e ovvie che è difficile capire perché facciano fatica ad entrare nelle aziende, almeno nella mia esperienza.
Ma attenzione! Entrare nelle aziende non significa solo quelle che utilizzano un bene e lo devono tenere sotto controllo, ma anche quelle che producono il bene.
C’è un lavoro di formazione da indirizzare verso i produttori che sembra o non essere mai partito o aver mancato totalmente il bersaglio.
Non ci sono informazioni affiabili senza dati di qualità e il mondo IT, scioccamente, sembra dire “scrivi qualcosa che poi ci penso io ad analizzarlo”, abituato come è a trattare dati complessi ed eterogenei salvo poi dover scendere a compromessi sul risultato.
Ogni dato va generato nel miglior modo possibile dentro il suo dominio di origine, lo capiremo?
