Quando un sensore IoT deve aprire un ticket invece di limitarsi ad allarmi e notifiche?

Perché la policy su ticket e allarmi va definita prima dei sensori IoT

Molti stabilimenti installano sensori IoT su compressori, motori e utility senza aver chiarito cosa deve succedere quando una grandezza esce soglia. Il risultato è prevedibile: centinaia di allarmi e notifiche su email e SMS, nessun ticket o ordine di lavoro strutturato, planner che ignorano le notifiche e direzione tecnica che chiede perché la manutenzione predittiva non ha ridotto i fermi.

La domanda non è tecnica ma di governance: per ogni famiglia di asset e livello di criticità, qual è l'esito operativo del flusso automatizzato? Monitoraggio silenzioso, allarme informativo, ticket da presa in carico, ordine di lavoro con checklist, o escalation multi-livello? Senza questa matrice, i dati di campo restano rumore.

Il responsabile di manutenzione e il direttore tecnico devono allineare produzione, automazione e HSE su poche regole ripetibili. L'obiettivo non è «fare IoT», ma ridurre il tempo tra anomalia rilevata e intervento tracciato — con impatto misurabile su MTTR (velocità di risposta) e, nel medio periodo, su MTBF (meno guasti ripetuti sullo stesso asset).

Matrice criticità asset: allarme, ticket o ordine di lavoro

Una pratica consolidata è classificare gli asset (A/B/C o equivalente RCM) e associare a ogni classe un esito automatico:

• Asset A (critici per produzione o safety): soglia superata → ticket ad alta priorità + generazione ordine di lavoro con checklist e notifica multicanale. Il planner non deve «ricordarsi» di aprire l'ODL.
• Asset B (importanti ma con ridondanza o margine): prima fase di allarmi e notifiche + ticket se la soglia persiste o si ripete entro N ore. Evita ODL su singolo spike.
• Asset C (basso impatto): solo dashboard e report settimanale; nessun ticket finché non si conferma il trend su finestra più lunga.

La stessa grandezza fisica (es. vibrazione su cuscinetto) può avere soglie e azioni diverse su due macchine identiche se una è su linea bottiglia e l'altra su servizio ausiliario.

Flussi automatizzati: dal segnale PLC o sensore all'azione nel CMMS

In ambito industriale il segnale può arrivare da sensori IoT dedicati (vibrazione, temperatura, corrente) o da tag già esposti dal PLC verso OPC-UA, Modbus o gateway di stabilimento. Il principio resta identico: un evento, una regola, un esito.

Un flusso tipico per la manutenzione predittiva su un compressore critico:

1. Il sensore supera la soglia di vibrazione (es. 5 mm/s RMS su frequenza bearing).
2. Il sistema registra l'evento con timestamp, asset e valore misurato.
3. Se la regola prevede conferma, attende N campioni o N minuti sopra soglia.
4. Genera ticket con priorità, asset e allegato del trend.
5. Opzionalmente apre ordine di lavoro con attività predefinite (ispezione, lubrificazione, sostituzione cuscinetto).
6. Invia allarmi e notifiche ai ruoli definiti (planner, capo turno, tecnico reperibile).

Il PLC può segnalare stati macchina (allarme, marcia, fermo) che non richiedono lo stesso trattamento della vibrazione: spesso conviene mappare bit di allarme processo su ticket urgente, mentre le grandezze analogiche restano su regole predittive progressive.

Quando bastano allarmi e notifiche (e quando no)

Allarmi e notifiche senza ticket sono accettabili in fase pilota o su asset non critici, a patto che:

• esista un owner che legge la dashboard almeno una volta per turno;
• le soglie siano conservative per limitare i falsi positivi;
• ci sia una revisione mensile degli allarmi ignorati.

Su asset A non è sufficiente: un'email persa in una casella condivisa equivale a un guasto non gestito. Il ticket nel CMMS crea backlog misurabile, SLA, assegnazione e storico — prerequisito per calcolare MTTR sulla fase «presa in carico → chiusura».

Allarmi e notifiche

Regola AL-VIB-01 · ultimo evento 14:33

Attiva

Soglia vibrazione superata · invio avviato

Canali configurati

Email

Team manutenzione · turno B

Inviato

SMS

+39 · Capo squadra A

Inviato

Push app

3 tecnici in servizio

In coda

Escalation se nessuna presa in carico entro 30 min

Email e SMS al team manutenzione

Allarmi su email, SMS e push: il turno interviene prima del guasto.

Falsi positivi e regole progressive

I falsi positivi saturano il reparto e distruggono la fiducia nella predittiva. Strategie operative:

• Soglia a due livelli: warning (solo dashboard) e critical (ticket).
• Conferma temporale: anomalia valida solo se persiste 15–30 minuti.
• Combinazione di grandezze: vibrazione alta + temperatura in salita, non vibrazione isolata.
• Revisione trimestrale delle regole con dati su ticket chiusi «non confermati» a guasto.

KPI: MTTR, MTBF e qualità del flusso predittivo

Il MTTR misura quanto velocemente il team chiude l'intervento dopo l'apertura del ticket o dell'ODL. Se la predittiva apre ticket in anticipo rispetto al guasto, il MTTR può salire leggermente (più lavoro preventivo) ma il downtime di produzione scende: è un trade-off che la direzione tecnica deve leggere insieme al tempo di fermo linea.

Il MTBF migliora quando gli interventi predittivi evitano rotture catastrofiche sullo stesso asset. Tracciate quanti ticket predittivi si sono conclusi con intervento effettivo vs chiusura «nessuna anomalia riscontrata»: un rapporto sano non è zero falsi positivi, ma non nemmeno il 80% di allarmi inutili.

Monitorate anche:

• tempo medio da soglia superata a ticket creato (latenza del flusso automatizzato);
• percentuale ticket predittivi chiusi entro SLA;
• numero di allarmi per asset per settimana (indice di rumore).

Approfondimento su metriche di ripristino nella sezione Statistiche e report e sul modulo Manutenzione predittiva.

Implementazione pratica in tre fasi

Fase 1 — Pilota su 3–5 asset critici: una regola per grandezza, esito ticket + notifica, review settimanale con planner e automazione.

Fase 2 — Standardizzazione: matrice criticità estesa, template di ODL da condizione, integrazione con Sensori IoT e gateway di stabilimento se i dati non arrivano ancora al CMMS.

Fase 3 — Ottimizzazione: affinamento soglie con storico guasti, collegamento a magazzino ricambi per ODL pre-compilati, report mensile per direzione su MTTR/MTBF per sito.

La manutenzione predittiva matura quando il flusso è noioso e ripetibile: stessi input, stessi esiti, stessi KPI — non quando ogni allarme diventa un'eccezione gestita a mano.