Integrare un ERP con il reparto produzione: il manuale di sopravvivenza

Il primo errore che vediamo fare è pensare che basti "collegare" i due mondi con un cavo di rete. Abbiamo visto progetti partire con la convinzione che bastasse "mettere uno switch in reparto e tirare un cavo verso la sala server". Non basta. Tra l'ERP e le macchine serve un traduttore — un middleware — che sappia leggere entrambi i linguaggi e che sia capace di fare una cosa fondamentale: decidere quali informazioni meritano di viaggiare, in quale direzione, e con quale tempistica.

Qui va chiarito un punto che genera confusione. Il middleware ben progettato copre buona parte di quello che si chiama MES (Manufacturing Execution System): raccolta dati di produzione, stato macchine, conteggio pezzi, gestione ordini in reparto. In molte PMI manifatturiere non serve un MES separato — serve un'integrazione fatta bene, che faccia da MES leggero per quello che la fabbrica usa davvero. In altre realtà, dove un MES strutturato già esiste, il middleware è il ponte tra MES e ERP. La domanda non è "MES sì o MES no": è quanto MES vi serve davvero.

Non tutto quello che una CNC può comunicare è utile per il gestionale. E non tutto quello che c'è nel gestionale ha senso mandarlo alla macchina. Capire cosa serve davvero è la parte difficile, e viene prima di scrivere una riga di codice. Chi salta questo passaggio si trova, sei mesi dopo, con un sistema che produce dati inutili e che nessuno guarda più.

Sui protocolli industriali, due coprono la maggioranza dei casi nella manifattura veneta. Più una terza categoria, meno citata ma onnipresente, di cui parliamo subito dopo.

Modbus è il veterano. Semplice, robusto, presente su quasi ogni PLC e macchina utensile degli ultimi 30 anni. Legge e scrive registri numerici. Ha un limite chiaro: non ha struttura semantica. Sapere che il registro 40001 contiene il valore 1247 non vi dice nulla finché qualcuno non consulta il manuale e scopre che quel numero è la temperatura del mandrino in decimi di grado. Ogni macchina ha la sua mappa, e la documentazione spesso esiste solo in un PDF stampato male in fondo a un cassetto del manutentore.

OPC-UA è il protocollo moderno. Strutturato, sicuro, autodescrittivo. Una macchina OPC-UA può dirvi "io sono una CNC, ho un mandrino, il mandrino ha una temperatura, e quella temperatura è 124.7 °C". La differenza è enorme in fase di integrazione e ancora più grande in fase di manutenzione futura: chi prenderà in mano il sistema tra cinque anni capirà i dati senza dover decifrare una mappa.

E poi c'è la realtà: i file. Una fetta importante delle integrazioni in fabbrica non passa né da OPC-UA né da Modbus, ma da cartelle condivise. Una macchina di laboratorio che droppa un CSV con i risultati delle analisi a fine controllo. Un terzista che vi manda l'avanzamento dei pezzi conto-lavoro via SFTP, una volta a turno. Un vecchio gestionale di reparto che esporta XML su una share di rete. Non è il flusso più moderno, ma è quello che la realtà del manifatturiero produce ogni giorno, e in molti contesti è l'unica strada percorribile. Un middleware fatto bene gestisce anche questo: monitora cartelle, valida i file in ingresso, riconosce i formati, gestisce i casi in cui il file arriva mezzo scritto perché la macchina è stata staccata. Saperlo fare bene è meno glamour che parlare di OPC-UA in una slide, ma è quello che separa un'integrazione che regge da una che si rompe al primo caso reale.

La realtà di un reparto tipico nel Veneto? Un mix di tutti e tre. Le macchine nuove parlano OPC-UA. Quelle con 15-20 anni di servizio parlano Modbus, se parlano. Strumenti di laboratorio e sistemi terzi scambiano file. Quelle ancora più vecchie hanno un'uscita seriale RS-232 e basta — e va recuperata con un convertitore. Il middleware deve gestire tutto, nello stesso impianto, spesso sulla stessa linea. Un'integrazione progettata "solo OPC-UA" è progettata per una fabbrica che non esiste.

Qui entriamo nel territorio delle illusioni costose. Un ERP transazionale — sia esso Zucchetti Ad Hoc, Mexal, Business Cube, Microsoft Dynamics o SAP Business One — è progettato per registrare fatti avvenuti, non per reagire in tempo reale al reparto. È una caratteristica di categoria, non un difetto di prodotto, e ignorarla è il modo più rapido per progettare un'integrazione che non funzionerà. Tre conseguenze pratiche.

1. "Real-time" è una parola che vende nelle slide, ma che applicata a un ERP transazionale significa progettare contro la natura del prodotto. L'integrazione corretta funziona così: il middleware legge dalla macchina in tempo reale (secondi), elabora, e scrive verso il gestionale in batch o a intervalli ragionevoli (minuti). Pretendere risposte in millisecondi dal gestionale è sbagliato nel design, non nella tecnologia.
2. L'accesso al database va trattato con rispetto. Alcuni ERP espongono API native, web service o connettori ufficiali; altri - soprattutto le installazioni on-premise più diffuse nel manifatturiero italiano - semplicemente non li hanno, e l'integrazione passa per letture e scritture dirette sul database. Non è di per sé un errore: è la realtà operativa di una larga fetta di progetti reali. Diventa un errore quando lo si fa senza protezioni. La regola d'oro? Non scrivere mai a cuore aperto sulle tabelle core dell'ERP. Si usano tabelle di frontiera (staging), isolate in un layer dedicato, pronte a essere riscritte se il fornitore del gestionale cambia gli schemi con un aggiornamento.
3. Le personalizzazioni cambiano tutto. Nessuna installazione di un ERP gestionale è uguale a un'altra. Negli anni si sono stratificate personalizzazioni, campi custom, automazioni del consulente di turno. Un'integrazione progettata senza guardare la vostra installazione - quale versione, quali moduli, quali campi aggiunti, quali automazioni esistenti - è una scommessa. Vale per Ad Hoc come per qualsiasi altro gestionale che abbia avuto la fortuna o la sfortuna di restare in azienda per dieci anni.

L'architettura che riteniamo solida per un'integrazione tra campo ed ERP segue tre strati netti. Non è un'invenzione del mondo industriale: è lo stesso principio di separazione dei livelli che applichiamo quando costruiamo un gestionale custom o un configuratore di prodotto. Cambia il dominio, non cambia l'idea.

Una nota subito: questi tre strati sono prima di tutto una separazione logica di responsabilità, non necessariamente di processi o macchine. In un progetto piccolo possono convivere dentro un solo servizio sullo stesso server, organizzati in moduli ben separati. In un progetto più grande, o con esigenze di resilienza maggiori, possono diventare componenti distinti su nodi diversi. Ciò che conta non è il numero di processi: è che le responsabilità non si mescolino mai.

Strato campo. La parte del sistema che parla con le macchine — OPC-UA, Modbus, file CSV monitorati su una share di rete, qualunque cosa serva. In un progetto piccolo è un modulo dentro il servizio principale, in scenari più complessi diventa un componente leggero che gira su un mini-PC industriale nel quadro elettrico o in armadio in reparto. La sua responsabilità è una sola: leggere dati, normalizzarli al volo, consegnarli a chi li userà. Quando questo strato è davvero separato — cioè è un agente distinto a bordo reparto — può anche bufferizzare i dati localmente in caso di rete giù, e sincronizzarli quando torna. Su impianti in cui la rete è critica, è la differenza tra una mezz'ora di switch impazzito che costa una giornata di dati persi e una stessa mezz'ora che non costa nulla.

Strato middleware. L'applicazione (la nostra è in Laravel quando il contesto lo permette, ma il punto non è il framework) che riceve i dati dallo strato campo, li arricchisce con il contesto gestionale — a quale ordine di produzione appartiene questo conteggio pezzi? — e li rende disponibili per il gestionale, per le dashboard, e per chiunque altro debba leggerli in futuro. È il livello dove vivono le regole di business, dove i dati grezzi diventano informazioni utili, e dove avvengono le trasformazioni che né le macchine né l'ERP saprebbero gestire. In un MES vero e proprio è questo il cuore del sistema; in integrazioni più snelle, è il livello che fa da MES leggero senza richiedere un prodotto separato.

Strato ERP. L'integrazione con il gestionale avviene qui, attraverso il canale che il prodotto offre: API ufficiali quando ci sono, web service quando esistono, accesso al database quando è l'unica strada disponibile. La regola non è "evitare il database a tutti i costi": è isolare il punto di contatto con il gestionale in un modulo dedicato, documentato, testato a ogni aggiornamento. Quando arriva un update che cambia uno schema, in un'integrazione fatta bene si tocca un solo file. In una fatta male, si caccia il bug per giorni.

L'errore più frequente, nei progetti che vediamo descritti o ereditati, è saltare lo strato middleware e far parlare le macchine direttamente con il gestionale. Funziona in demo, e funziona anche per le prime settimane in produzione. Poi alla prima piccola variazione — una macchina nuova, un cambio di versione del gestionale, un firewall che blocca una porta, un commerciale che vuole un report che prima non serviva — crolla tutto. E il problema non è che si rompe: è che non si capisce nemmeno dove si è rotto, perché la logica è spalmata tra cinque punti diversi.

Studiando i progetti di integrazione — quelli che abbiamo fatto, quelli che ci è capitato di ereditare, quelli che ci vengono raccontati da chi ci lavora — emerge un pattern. Questi sistemi non falliscono per ragioni tecniche esotiche. Falliscono per quattro motivi banali, che si ripetono.

1. Si parte da cosa si può leggere, non da cosa serve. Si guardano le macchine, si scopre che espongono temperatura, pressione, vibrazioni, cicli, allarmi, e si decide di leggere tutto. Sei mesi dopo, la dashboard mostra quaranta grafici che nessuno guarda. Il punto non è cosa si può leggere: è quali due o tre numeri cambieranno una decisione che oggi prendete a sentimento.
2. Si sottovaluta la rete di fabbrica. La rete dell'ufficio non è la rete del reparto: interferenze elettromagnetiche, switch non gestiti, cablaggi tirati negli anni senza criterio. Un cavo dati che corre nella stessa canalina dei cavi di potenza di un motore può far perdere pacchetti ogni volta che il motore parte — e si finisce a cercare un bug nel software per giorni, quando il problema era a due metri di canalina. La rete va verificata prima, non quando le cose non tornano.
3. Si costruisce per una persona, non per un processo. "Lo facciamo come lo vuole il nostro responsabile di produzione." Poi il responsabile cambia azienda, e il successore vuole vedere altro. Se il sistema è stato disegnato attorno a una persona, va riscritto. Se è stato disegnato attorno ai dati e ai processi, basta una nuova vista.
4. Non si pensa a chi lo manterrà tra tre anni. È la madre di tutti i problemi. Middleware scritto in un linguaggio di nicchia, da un consulente che poi sparisce, senza documentazione: tre anni dopo avete un sistema che nessuno osa toccare. Stack noti, documentazione viva, codice sorgente vostro per contratto. Non sono dettagli da capitolato: sono la differenza tra un asset e una bomba a orologeria.

Se state valutando preventivi per un progetto di questo tipo, queste cinque domande vi diranno più di qualsiasi presentazione. Non c'è una risposta "giusta" da incastrare: conta il modo in cui il fornitore ragiona ad alta voce.

1. "Avete fatto un sopralluogo tecnico prima del preventivo?"
   Un preventivo scritto senza aver visto le macchine, la rete e l'installazione del gestionale è una scommessa travestita da offerta. La risposta giusta descrive una giornata in fabbrica, non un listino.
2. "Come parlate con il nostro gestionale?"
   Aspettatevi una risposta specifica — API, web service, database, e con quali accortezze. Una risposta vaga su un tema così centrale dice molto.
3. "Cosa succede ai dati se la rete in reparto cade per due ore?"
   Una risposta solida parla di code locali e sincronizzazione al ritorno. Una risposta che minimizza il problema è essa stessa il problema.
4. "Il codice sorgente alla fine è nostro?"
   La risposta che tutela voi è sì. Se il codice resta al fornitore "per proteggere il know-how", state firmando una dipendenza, non un progetto.
5. "Tra tre anni, se non lavorassimo più con voi, chi può mettere mano al sistema?"
   Non esiste la risposta perfetta. Ma una risposta onesta — stack diffusi, documentazione, formazione del vostro IT — vale più di qualsiasi certificazione appesa in sala riunioni.

Il primo passo non è chiedere un preventivo. È un sopralluogo tecnico: una o due giornate in azienda per mappare macchine, rete, gestionale e processi, e capire cosa serve davvero. Costa poco, evita decisioni costose, e a volte porta a una conclusione onesta — che il progetto, così com'è immaginato, non vale la pena farlo. Riteniamo sia un'analisi utile a prescindere da chi poi sviluppa.

Sui tempi e sui costi non diamo numeri al buio: dipendono da quante macchine ci sono, da come parlano, dallo stato della rete e da cosa volete farci davvero coi dati. Per dare un ordine di grandezza, un'integrazione su un reparto di poche macchine, dall'analisi alla messa in produzione, si misura in mesi, non in settimane — ed è bene diffidare di chi promette tempi da weekend.

Resta una domanda che vale per noi quanto per chiunque altro valutiate: con chi avete a che fare. Mostrum è una software house di Vicenza: il nostro lavoro di tutti i giorni è costruire gestionali che reggono processi complessi e configuratori che traducono le regole di prodotto di un'azienda in software. Un'integrazione tra ERP e reparto, vista da vicino, è in buona parte lo stesso problema: dati che devono restare coerenti, regole di business che devono essere esplicite, un sistema che deve sopravvivere agli anni e a chi lo manterrà dopo di noi.

Se cerchi un partner che parte dal problema, ragiona prima di scrivere codice e ti lascia padrone del tuo sistema, parliamone. Senza impegno.