Perché il downtime non è quasi mai dove pensi (e come identificarlo davvero)
Nel contesto produttivo, quando una linea si ferma, la prima reazione è quasi sempre la stessa:
“Abbiamo un problema sulla macchina X”
Nella maggior parte dei casi, questa è un’ipotesi. E molto spesso è sbagliata.
Il downtime reale, quello che impatta davvero l’OEE e la produttività, raramente coincide con la causa più visibile.
IL PROBLEMA: SI INTERVIENE SULL’EFFETTO
Nelle analisi standard, il downtime viene classificato così:
- guasto macchina
- cambio stampo/modello
- mancanza materiale
- errore operatore
Queste categorie sono utili per reporting, ma non spiegano il problema reale.
Esempio tipico:
- fermo macchina → classificato come guasto
- intervento → sostituzione componente
- ripartenza → OK
Dopo poche ore, il problema si ripresenta.
Perché?
Perché la causa reale non era il componente.
IL DOWNTIME REALE È SPESSO SISTEMICO
Nella pratica sul campo, i fermi più critici derivano da:
- condizioni processo instabili
- parametri fuori controllo ma “accettati”
- derive lente che non generano allarmi
- interazioni tra macchina, materiale e operatore
Questo tipo di problemi:
- non si vedono subito
- non vengono registrati correttamente
- vengono attribuiti alla macchina
IL FALSO MITO: “SERVE PIÙ MANUTENZIONE”
Una delle conclusioni più frequenti è:
“Serve più manutenzione preventiva”
Nella realtà, questo spesso porta a:
- più interventi programmati
- più costi
- stesso livello di downtime
Perché il problema non è la manutenzione.
È la mancanza di diagnosi reale del processo.
COME IDENTIFICARE IL PROBLEMA REALE
Un’analisi efficace non parte dalla macchina, ma da tre livelli.
- Analisi temporale reale
Non solo “quanto downtime”, ma:
- quando succede
- in quali condizioni
- con che frequenza
- Correlazioni tra eventi
Cosa succede prima del fermo:
- variazioni ciclo
- micro-fermi
- derive qualità
- Distinzione tra causa e trigger
Esempio:
- trigger → sensore che blocca la macchina
- causa → instabilità che porta il sensore fuori soglia
Se analizzi il trigger, non risolvi il problema.
IL RISCHIO: OTTIMIZZARE I DATI SBAGLIATI
Molti sistemi OEE mostrano numeri precisi, ma:
- aggregano cause diverse
- semplificano dinamiche complesse
- non distinguono fenomeni reali
Risultato:
si ottimizza ciò che è misurato, non ciò che genera il problema.
COSA CAMBIA CON UN APPROCCIO CORRETTO
Quando il downtime viene analizzato correttamente:
- i fermi ricorrenti diminuiscono
- gli interventi diventano mirati
- la manutenzione si riduce
- l’OEE cresce per cause reali
CONCLUSIONE
Il problema non è quanto si ferma una macchina.
È perché si ferma davvero.
Finché si lavorerà sulle cause apparenti: si continueranno a gestire effetti, non eliminare problemi.
Il salto di qualità avviene quando si passa da:
registrare i fermi → capire il processo che li genera