Un fermo di 12 minuti su una linea non è un dato isolato. Se si ripete otto volte al giorno, su tre turni e cinque giorni alla settimana, diventa capacità produttiva non disponibile, consegne sotto pressione e margini erosi. Questo case study riduzione fermi impianto descrive un approccio concreto applicabile a un...
Il contesto: fermi visibili, cause poco dimostrabili
Lo stabilimento considerato dispone di quattro linee automatiche, con PLC Siemens S7 su macchine più recenti e controllori Modbus TCP/IP su alcune utenze ausiliarie. L’ERP gestisce ordini e consuntivazione, mentre i dati di produzione vengono riportati dagli operatori a fine turno e integrati, dove possibile, con esportazioni da pannelli HMI.
Il direttore di stabilimento individua tre criticità. La prima è la discrepanza tra il tempo di fermo percepito dal reparto e il fermo dichiarato nei rapporti. La seconda è l’uso eccessivo della causale generica "guasto macchina", che non consente di separare un problema di alimentazione, un allarme di sicurezza, un difetto del materiale o un’attesa logistica. La terza è l’assenza di una vista condivisa tra manutenzione, produzione e pianificazione.
Prima del progetto, l’OEE medio rilevato era del 58%. Il dato era utile come indicazione generale, ma non abbastanza solido per guidare investimenti. Le microfermate sotto i tre minuti spesso non venivano registrate, i fermi prolungati venivano classificati a posteriori e la disponibilità della linea non era correlata con il prodotto lavorato o con il lotto di materia prima.
Come è stato impostato il progetto di riduzione dei fermi
L’obiettivo non era installare un nuovo livello di supervisione complesso. Era rendere disponibili dati operativi affidabili, senza introdurre server locali da gestire né fermare la produzione per lunghi interventi di integrazione.
Il progetto è stato suddiviso in una fase di misura, una fase di qualificazione delle causali e una fase di miglioramento. Questa sequenza è decisiva: intervenire prima di avere una base dati attendibile porta spesso a correggere il sintomo più evidente, non la perdita più costosa.
1. Acquisizione diretta dal PLC e normalizzazione degli stati
Sono stati selezionati i segnali necessari per distinguere in automatico macchina in marcia, ferma, in allarme, in setup, in attesa materiale e in condizioni di sicurezza. Non tutti i PLC espongono gli stati con la stessa logica. Per questo la mappatura iniziale ha incluso sia i bit di stato già presenti sia alcuni contatori e codici allarme disponibili sulle HMI.
L’agente on-premise ha raccolto i segnali dai controllori e li ha inviati alla piattaforma cloud. Il punto tecnico non è solo acquisire il tag: è normalizzarlo in uno stato produttivo comprensibile e confrontabile tra linee diverse. Un allarme attivo, per esempio, non equivale sempre a un fermo. Può essere una segnalazione transitoria che non interrompe il ciclo. La logica di classificazione deve quindi essere validata con chi conosce davvero la macchina.
La raccolta è stata associata a timestamp coerenti, conteggio pezzi buoni, scarti e velocità istantanea. In parallelo, l’integrazione con l’ERP ha permesso di contestualizzare i dati per ordine, codice prodotto e turno. Con PLCinCloud, questa architettura può essere realizzata tramite protocolli industriali nativi e accesso browser, evitando di costruire un’infrastruttura di raccolta dati custom in stabilimento.
2. Causali: automatiche dove possibile, guidate dove serve
Il secondo passaggio ha riguardato le causali di fermo. Le categorie iniziali erano troppe e poco omogenee: oltre 30 voci, diverse per ciascun reparto, con descrizioni sovrapposte. Il risultato era un archivio difficile da analizzare e quasi impossibile da usare per confronti affidabili.
Le causali sono state ridotte a una struttura operativa: fermo per guasto, attesa materiale, cambio formato, qualità, pulizia, assenza operatore, attesa autorizzazione e fermo pianificato. Ogni macrocausale ha poi mantenuto sottocause specifiche per linea, utili alla manutenzione e al miglioramento continuo.
Quando il PLC forniva un codice allarme significativo, la causale veniva proposta automaticamente. Quando invece la macchina si fermava senza un evento diagnostico univoco, l’operatore doveva confermare una causale da interfaccia semplice. È un compromesso necessario: automatizzare tutto può produrre classificazioni errate; affidarsi solo all’inserimento manuale riduce la qualità del dato nei momenti più concitati del turno.
3. Dashboard per decisioni di turno, non solo report mensili
Il cruscotto di reparto è stato configurato con pochi KPI, ma azionabili: disponibilità per linea, minuti di fermo per causale, numero di microfermate, velocità reale rispetto al target, pezzi buoni, scarti e OEE per ordine. La visualizzazione è stata resa disponibile a responsabili di produzione, manutenzione e pianificazione con livelli di dettaglio differenti.
Il cambiamento più concreto è avvenuto nel passaggio di consegne. Ogni turno ha iniziato a discutere non più di impressioni generali, ma dei tre eventi che avevano generato più minuti persi. Se un fermo si ripeteva su più turni, veniva aperta un’azione con responsabile e data di verifica. Questa disciplina operativa vale più di una dashboard ricca di grafici non utilizzati.
I risultati dopo 12 settimane
Nelle prime due settimane, i dati hanno evidenziato una situazione diversa da quella ipotizzata. Il guasto meccanico non era la causa principale di indisponibilità. Il 34% dei minuti persi derivava da attese di materiale e anomalie di alimentazione, mentre le microfermate legate a sensori e accumulo a valle incidevano più di quanto risultasse dai rapporti manuali.
Sono stati avviati tre interventi: revisione del rifornimento a bordo linea, regolazione delle soglie di accumulo e manutenzione mirata su due gruppi sensore. Per le attese materiale è stata introdotta una segnalazione preventiva basata sullo stato macchina e sul consumo del lotto. Per le microfermate, la manutenzione ha lavorato sugli allarmi ricorrenti anziché su una generica lista di guasti segnalati a fine settimana.
Dopo 12 settimane, i minuti di fermo non pianificato sulle linee coinvolte si sono ridotti del 27%. La disponibilità media è passata dal 71% al 79%, mentre l’OEE è cresciuto dal 58% al 64%. Il miglioramento non è attribuibile soltanto alla piattaforma dati: deriva dalla combinazione tra rilevazione automatica, causali utilizzabili e responsabilità chiare sulle azioni correttive.
Un ulteriore beneficio è stato la riduzione del tempo speso per preparare i report. Prima, produzione e manutenzione impiegavano diverse ore a settimana per ricostruire gli eventi da fonti differenti. Con dati centralizzati, il confronto è diventato più rapido e meno conflittuale. Non significa eliminare le discussioni tecniche, ma portarle su fatti condivisi.
Cosa rende replicabile questo case study di riduzione fermi impianto
Il primo fattore è partire da una linea pilota significativa. Scegliere la linea con più problemi non è sempre la scelta migliore: può avere logiche obsolete o condizioni così eccezionali da rendere difficile validare il modello. Una linea rappresentativa, con volumi adeguati e personale coinvolto, permette di stabilire standard replicabili.
Il secondo fattore è definire prima la semantica del dato. Cosa separa una microfermata da un fermo? Quando inizia il setup? L’attesa materiale è un problema della linea, della logistica interna o della pianificazione? Senza risposte condivise, i KPI possono essere tecnicamente corretti ma gestionalmente inutili.
Il terzo fattore è non confondere il dato real-time con il controllo in tempo reale. Per ridurre i fermi, nella maggior parte dei casi è sufficiente leggere in modo affidabile PLC, contatori e stati macchina, integrandoli con i contesti ERP. Modificare la logica di comando della macchina è un tema diverso, con requisiti di sicurezza, validazione e responsabilità ben più elevati.
Misurare prima di investire nella macchina sbagliata
Molte aziende pianificano un revamping convinte che il limite sia nella velocità nominale dell’impianto. Talvolta è vero. In altri casi, aumentare la velocità massima amplifica instabilità, scarti e tempi di recupero. Se il collo di bottiglia è l’alimentazione, il cambio formato o la qualità del materiale, il ritorno dell’investimento può essere inferiore alle attese.
La riduzione dei fermi non richiede necessariamente un progetto IT esteso. Richiede una connessione affidabile ai dati di fabbrica, una classificazione costruita attorno ai processi reali e un rito operativo che trasformi ogni evidenza in una decisione. Quando questi elementi sono presenti, il dato PLC smette di essere un segnale tecnico isolato e diventa capacità produttiva da recuperare, turno dopo turno.