Integrazione ERP per la manifattura: collegare SAP, Dynamics e Navision al reparto produttivo

Ogni azienda che usa insieme un ERP e sistemi di reparto prima o poi si scontra con la stessa discrepanza. L’ERP mostra un ordine come completato; il reparto sa che due pallet sono stati rilavorati. L’ERP mostra il materiale consumato a quantità standard; il consumo reale comprendeva scarti che nessuno ha registrato. Nessuno dei due sistemi mente: descrivono momenti diversi — l’ERP descrive il piano e le sue conseguenze economiche, il reparto descrive la realtà fisica — e l’integrazione è la disciplina che tiene riconciliate quelle due descrizioni.

La prima decisione di progettazione è la direzione della titolarità del dato, e sbagliarla è la causa più comune di integrazioni che non si stabilizzano mai. I dati anagrafici — clienti, fornitori, materiali, distinte base, cicli, prezzi — appartengono all’ERP e fluiscono verso il basso. I dati di esecuzione — orari reali di inizio e fine, quantità realmente prodotte, scarti, causali di fermo, stati macchina, assegnazioni degli operatori, consumo reale di materiale — nascono in reparto e fluiscono verso l’alto. Quando entrambi i sistemi possono modificare la stessa entità, non avete un’integrazione: avete una discussione ricorrente con un calendario di sincronizzazione.

Il flusso discendente è di norma la metà più semplice. Gli ordini di produzione rilasciati in ERP compaiono nel MES con le loro operazioni, cicli e liste materiali. Le variazioni anagrafiche si propagano. I dati di cliente e consegna raggiungono i sistemi che ne hanno bisogno. La difficoltà pratica principale è la granularità: un ordine di produzione ERP corrisponde spesso a diverse operazioni di reparto su centri di lavoro differenti, e la mappatura tra la struttura ERP e quella eseguibile va definita deliberatamente e non data per scontata.

Il flusso ascendente è dove sta il valore e dove si concentra la difficoltà. Le conferme — i messaggi che dicono che questa operazione ha prodotto questa quantità, consumato questo materiale, richiesto questo tempo e scartato questo tanto — alimentano giacenze, costi e capacità dell’ERP. Quando vengono raccolte automaticamente da macchine e terminali operatore anziché digitate a fine turno a memoria, i numeri dell’ERP smettono di essere approssimazioni. Il calcolo dei costi migliora immediatamente, perché i tempi reali sostituiscono quelli standard.

I pattern di integrazione disponibili differiscono soprattutto per latenza e accoppiamento. Lo scambio via file è semplice, supportato ovunque e inevitabilmente orientato al batch. L’accesso diretto al database è veloce e fragile, e si rompe durante gli aggiornamenti del fornitore in modi difficili da prevedere. Le API REST e SOAP — SAP via IDoc, BAPI o OData; Dynamics 365 e Business Central tramite le loro API pubblicate — sono il default moderno e gestiscono il versioning molto meglio. Le code di messaggi aggiungono resilienza per eventi ad alta frequenza, perché il reparto continua a produrre dati indipendentemente dalla disponibilità dell’ERP.

Quest’ultimo punto merita enfasi perché è dove le integrazioni fragili si rivelano. La produzione non si ferma quando si ferma l’ERP. Se la vostra integrazione è sincrona e l’ERP è indisponibile per manutenzione programmata, o si ferma il reparto o si perdono i dati. Un design bufferizzato a code permette al MES di continuare a raccogliere e di consegnare l’arretrato quando la connessione torna — e in una fabbrica su più turni non è un caso limite, ma una realtà mensile.

I sistemi ERP locali e regionali complicano il quadro in modo specifico. Le suite globali hanno interfacce documentate e grandi ecosistemi di integrazione. I prodotti regionali — Panteon, Logo, Nebim e i loro equivalenti in altri mercati — sono diffusi tra le aziende di media dimensione, spesso profondamente personalizzati, e raramente dispongono di un connettore MES pronto all’uso. Non è una ragione per sostituire un ERP che funziona. È una ragione per trattare il livello di integrazione come parte di primo piano del progetto anziché come un dettaglio dato per scontato.

La riconciliazione è la parte che viene omessa dai piani di progetto e che poi consuma i primi tre mesi di esercizio. I messaggi falliscono. Una conferma viene rifiutata perché un materiale era bloccato. Un ordine di produzione viene cancellato in ERP dopo che il reparto lo ha già avviato. Ogni integrazione ha bisogno di una coda ispezionabile, di un meccanismo di ritentativo, di uno stato di errore che avvisi una persona e di un report periodico di riconciliazione che dimostri che quanto registrato in reparto e quanto contenuto nell’ERP continuano a coincidere. Le integrazioni prive di questi elementi non falliscono rumorosamente: derivano in silenzio, il che è peggio.

Il consiglio di perimetro che regge all’impatto con la realtà: partite da un tipo di ordine su una sola linea, dimostrate l’intero giro completo dal rilascio in ERP all’esecuzione in reparto alla conferma di ritorno in ERP, e solo dopo allargate. Le integrazioni big bang su tutti gli stabilimenti e tutti i tipi di ordine contemporaneamente falliscono in modi estremamente difficili da diagnosticare, perché quando tutto è nuovo nulla può essere usato come riferimento.