In molti stabilimenti il MES sa esattamente quando una linea si ferma, ma quell'informazione resta confinata nei suoi cruscotti. Il capoturno chiama il manutentore via radio, qualcuno apre un ticket a mano sul CMMS, intanto i minuti passano e l'OEE crolla. Il problema non sta nella tecnologia disponibile, sta nella mancanza di un ponte affidabile tra il sistema che vede l'allarme e il sistema che gestisce l'intervento. Integrare MES e CMMS non significa solo "fare passare un JSON": significa filtrare il rumore degli allarmi, mappare correttamente i codici evento, garantire tracciabilità e poter spegnere il flusso in sicurezza quando serve. In questa guida vediamo come si imposta un'integrazione MES-CMMS robusta partendo da un caso concreto su una linea di imbottigliamento.
Il caso reale: linea imbottigliamento da 24.000 bph
Prendiamo uno stabilimento beverage con una linea da 24.000 bottiglie/ora. Il MES rileva fermi su riempitrice, etichettatrice e fardellatrice, ma li notifica solo via dashboard. Il tempo medio di apertura ticket manuale era di 7 minuti, di cui 3 spesi a identificare la macchina corretta e la matricola. Su un MTTR medio di 28 minuti, quei 7 minuti pesavano per il 25%. L'obiettivo dell'integrazione è stato dichiarato fin dal kick-off: portare a zero il tempo di "apertura amministrativa" del ticket e agganciare ogni intervento alla scheda asset giusta senza errori di trascrizione.
Cosa serve davvero prima di scrivere codice
Prima di toccare un endpoint REST conviene sedersi con il responsabile MES, il capo manutenzione e l'IT. I punti da chiarire sono pochi ma critici:
- quali codici evento del MES devono generare un ticket e quali no;
- come si chiama univocamente ogni macchina nei due sistemi (matricola, asset code, tag);
- chi e' il team assegnatario di default per tipologia di guasto;
- qual e' la soglia oltre la quale un fermo diventa "vero" e non un microstop;
- cosa deve succedere quando il ticket viene chiuso sul CMMS.
Architettura dell'integrazione passo per passo
Manutentya espone endpoint REST HTTPS documentati per le tre operazioni fondamentali: apertura ticket, aggiornamento stato e chiusura. Lo schema JSON e gli esempi di payload sono scaricabili dall'area tecnica insieme alla documentazione PDF fornitore, che il team IT puo girare direttamente al system integrator del MES senza passaggi intermedi.
1. Autenticazione e perimetro di sicurezza
Ogni chiamata dal MES viaggia con un Bearer token generato a livello di stabilimento o, nei casi piu' delicati, di singola linea. Lo scope del token e' volutamente ridotto alle sole operazioni di creazione ticket e lettura stato: il MES non puo' modificare anagrafiche, ne' cancellare interventi storici. Se un token finisce esposto in un log o in una pipeline CI, si revoca dal pannello in pochi secondi senza fermare le altre linee. Nel caso della linea da 24.000 bph abbiamo emesso tre token distinti, uno per ogni isola produttiva, in modo che un audit possa risalire subito all'origine di una chiamata anomala.
2. Anti-flapping: il filtro che salva la giornata
Senza un filtro temporale, una fotocellula sporca su una fardellatrice puo' generare 200 ticket in un'ora. Manutentya consente di configurare una soglia anti-flapping parametrica per macchina: il ticket viene aperto solo se il fermo persiste oltre il delay impostato. Sulla riempitrice abbiamo messo 90 secondi, sulla fardellatrice 45, sull'etichettatrice 30. Il risultato e' stato un calo dei ticket "spuri" da 60 al giorno a meno di 5, restituendo credibilita' al sistema agli occhi dei manutentori che prima ignoravano meta' delle notifiche.
3. Mappatura allarme-intervento
Questa e' la tabella che fa la differenza fra un'integrazione che funziona e una che diventa un problema. La mappatura allarme-intervento e' gestita centralmente per ogni sede produttiva e converte ciascun codice evento MES in una terna ticket coerente.
- Codice MES RIE_T101 → tipologia "Perdita prodotto", priorita' Alta, team Meccanico.
- Codice MES ETI_S204 → tipologia "Disallineamento etichetta", priorita' Media, team Elettrico.
- Codice MES FAR_F310 → tipologia "Microstop film", priorita' Bassa, team Conduttori di linea.
Questa tabella vive nel CMMS, non nel MES: questo permette al capo manutenzione di rivederla senza coinvolgere il fornitore MES ad ogni cambio organizzativo.
4. Identificazione macchinario e aggancio asset
Quando il MES invia il payload, Manutentya esegue un riconoscimento automatico tramite matricola o asset code. Se la macchina e' anagrafata, il ticket viene immediatamente collegato alla scheda macchinario e ai contatori ore di funzionamento. Questo elimina l'errore tipico del manutentore che aggancia il ticket alla "Linea 2 generica" invece che alla specifica fresatrice CNC o all'estrusore corretti, distorcendo le statistiche MTBF e MTTR.
"Nei primi due mesi di integrazione abbiamo abbattuto il tempo di apertura ticket da 7 minuti a 9 secondi e ridotto del 18% l'MTTR complessivo. Il dato piu' inatteso, pero', e' stato vedere il vero peso dei microstop sulla fardellatrice: senza l'anti-flapping non ce ne saremmo mai accorti." - Responsabile manutenzione, stabilimento beverage Nord Italia
Chiusura del loop: bidirezionalita' e audit
Un'integrazione monodirezionale risolve a meta'. Manutentya supporta l'aggiornamento bidirezionale: il MES puo' interrogare lo stato del ticket per autorizzare il riavvio della produzione solo quando l'intervento risulta chiuso, oppure ricevere webhook opzionali sui cambi di fase (preso in carico, in lavorazione, in attesa ricambi, chiuso). Sulla nostra linea da 24.000 bph, il MES blocca il reset della riempitrice finche' il manutentore non firma elettronicamente la chiusura: questo ha azzerato i riavvii prematuri che prima causavano un secondo fermo nel giro di pochi minuti.
Log, audit e ambiente di test
Ogni chiamata API viene salvata nel registro chiamate con timestamp, payload completo, esito e codice HTTP di risposta. Questo log e' fondamentale per il troubleshooting (capire se un ticket non e' arrivato per un 401 o per un 422) e per le verifiche di conformita' interna, specie negli stabilimenti certificati ISO 9001 o operanti in ambito food. Prima del go-live, infine, conviene sempre testare le chiamate nella sandbox dedicata: l'ambiente di prova replica la logica produttiva, valida i payload e permette al system integrator MES di simulare scenari di errore (token scaduto, asset inesistente, codice allarme non mappato) senza generare ticket fantasma sull'operativo.
Conclusione
Un'integrazione MES-CMMS ben fatta non si misura dal numero di endpoint chiamati, ma dalla qualita' dei ticket che genera e dalla fiducia che i manutentori ripongono nelle notifiche. Token con scope ristretto, anti-flapping per macchina, mappatura centralizzata e log auditabile sono i quattro pilastri che separano un progetto stabile da una continua emergenza. Se vuoi vedere come configurare questi flussi sulla tua linea produttiva, dai un'occhiata al modulo Integrazione MES di Manutentya oppure puoi richiedere una demo con un nostro consulente per simulare insieme un caso reale sul tuo MES.