Integrarea ERP pentru Producție: Conectarea SAP, Dynamics și Navision la Hala de Producție

Orice producător care rulează atât un ERP, cât și sisteme în hală ajunge în cele din urmă la aceeași discrepanță. ERP-ul arată comanda ca finalizată; hala știe că doi paleți au fost reprelucrați. ERP-ul arată materialul consumat la cantitatea standard; consumul real a inclus rebuturi pe care nu le-a înregistrat nimeni. Niciun sistem nu minte. Ele descriu momente diferite — ERP-ul descrie planul și consecințele lui financiare, hala descrie realitatea fizică — iar integrarea este disciplina de a menține aceste două descrieri reconciliate.

Prima decizie de proiectare este direcția proprietății, iar greșirea ei este cea mai frecventă cauză a integrărilor care nu se stabilizează niciodată. Datele de bază — clienți, furnizori, materiale, liste de materiale, fișe tehnologice, prețuri — aparțin ERP-ului și curg în jos. Datele de execuție — ore reale de început și sfârșit, cantități produse efectiv, rebuturi, motive de oprire, stări ale mașinilor, repartizarea operatorilor, consumul real de material — se generează în hală și curg în sus. Când ambele sisteme au voie să editeze aceeași entitate, nu aveți o integrare, ci o ceartă recurentă cu program de sincronizare.

Fluxul descendent este de obicei jumătatea mai simplă. Comenzile de producție lansate în ERP apar în MES cu operațiile, fișele tehnologice și listele de materiale. Modificările de nomenclator se propagă. Datele de client și de livrare ajung la sistemele care au nevoie de ele. Principala dificultate practică este granularitatea: o comandă de producție din ERP corespunde frecvent mai multor operații în hală, pe centre de lucru diferite, iar maparea între structura ERP și structura executabilă trebuie definită deliberat, nu presupusă.

Fluxul ascendent este acolo unde stă valoarea și unde se concentrează dificultatea. Confirmările — mesajele care spun că această operație a produs această cantitate, a consumat acest material, a durat atât și a rebutat atât — alimentează cifrele de stoc, de costuri și de capacitate din ERP. Când acestea sunt captate automat de la mașini și terminale de operator, nu tastate la sfârșitul schimbului din memorie, cifrele ERP-ului încetează să mai fie aproximări. Calculația de cost se îmbunătățește imediat, pentru că timpii reali înlocuiesc timpii standard.

Tiparele de integrare disponibile diferă mai ales prin latență și cuplare. Schimbul prin fișiere este simplu, universal suportat și inevitabil orientat pe loturi. Accesul direct la baza de date este rapid și fragil, cedând la actualizările furnizorului în moduri greu de anticipat. API-urile REST și SOAP — SAP prin IDoc, BAPI sau OData; Dynamics 365 și Business Central prin API-urile lor publicate — sunt varianta implicită modernă și suportă mult mai elegant schimbarea de versiune. Cozile de mesaje adaugă reziliență pentru evenimentele de frecvență mare, pentru că hala continuă să producă date indiferent dacă ERP-ul este disponibil sau nu.

Acest ultim punct merită subliniat, pentru că acolo se demască integrările fragile. Producția nu se oprește când se oprește ERP-ul. Dacă integrarea este sincronă și ERP-ul este indisponibil pentru mentenanță programată, ori se oprește hala, ori se pierd datele. Un design cu cozi și tampon permite MES-ului să continue colectarea și să livreze restanțele când revine conexiunea — iar într-o fabrică cu mai multe schimburi, acesta nu este un caz-limită, ci o realitate lunară.

Sistemele ERP locale și regionale complică tabloul într-un mod aparte. Suitele globale au interfețe documentate și ecosisteme mari de integrare. Produsele regionale — Panteon, Logo, Nebim și echivalentele lor din alte piețe — sunt răspândite printre producătorii mijlocii, adesea puternic personalizate, și rareori au un conector MES de raft. Acesta nu este un motiv pentru a înlocui un ERP care funcționează. Este un motiv pentru a trata stratul de integrare ca pe o parte de primă importanță a proiectului, nu ca pe un detaliu presupus.

Reconcilierea este partea omisă din planurile de proiect și care apoi consumă primele trei luni de operare. Mesajele eșuează. O confirmare este respinsă pentru că un material era blocat. O comandă de producție este ștearsă în ERP după ce hala a început-o deja. Orice integrare are nevoie de o coadă pe care o puteți inspecta, de un mecanism de reluare, de o stare de eroare care alertează un om și de un raport periodic de reconciliere care dovedește că ce a înregistrat hala și ce ține ERP-ul încă se potrivesc. Integrările fără acestea nu eșuează zgomotos; derivează în tăcere, ceea ce este mai rău.

Sfatul de perimetru care rezistă la contactul cu realitatea: începeți cu un singur tip de comandă pe o singură linie, dovediți circuitul complet de la lansarea din ERP la execuția în hală și înapoi la confirmarea în ERP, și abia apoi extindeți. Integrările big-bang, pe toate fabricile și toate tipurile de comandă simultan, eșuează în moduri extrem de greu de diagnosticat, pentru că atunci când totul este nou, nimic nu poate servi drept referință.