ERP-integráció és folyamatdigitalizálás

SAP, Dynamics, NetSuite, Odoo és számos regionális ERP szabványos konnektorokon keresztül; bármely más rendszer REST API-n vagy fájlcserén keresztül.

Az integrációs réteg leképezi az egyedi mezőket és logikát. A testreszabás tehát megszokott dolog.

Az MSF kiegészíti az ERP-t: a pénzügy és a kereskedelem ott marad, ahol van, Ön pedig egy gyártási réteget nyer mellé.

Befelé jellemzően gyártási rendelések, cikktörzs, darabjegyzékek, művelettervek és készletszintek. Kifelé rendelés- és műveletvisszajelentések, gyártott és selejt mennyiségek, anyagfelhasználás és minőségi eredmények. A vita mindig arról szól, hogy melyik rendszeré az adott mező, és mi történik, ha mindkettőben módosítják. Mezőnként tisztázzák, melyik rendszer a mester az adott adatra, mielőtt bárki leképezést írna, mert ezt a döntést később drága visszacsinálni.

Igen, ha a visszajelentéseknek vissza kell könyvelődniük. Minden, ami készletmozgást könyvel vagy műveletet zár le, írás, és az ERP-csapat ezt jó eséllyel hivatalosan támogatott interfészeken keresztül szeretné látni (BAPI-n, OData-szolgáltatáson vagy staging táblán), nem közvetlen adatbázis-hozzáféréssel. Az első, csak olvasó fázis teljesen ésszerű: rendeléseket húzunk le, megjelenítjük őket az üzemben, a könyvelés pedig marad kézi, amíg a számok össze nem érnek.

Hetek, ha van nevesített felelős az ERP-oldalon, az éleshez hasonló tesztrendszer, egyeztetett interfészek és nagyjából rendben lévő törzsadat; hosszabb, ha nincs. A konnektor megírása ritkán a szűk keresztmetszet. Az idő a változáskezelési ablakokra és a transzport-jóváhagyásokra való várakozással megy el, meg azzal, amíg valaki megmondja, hogy a négy cikkszám közül melyik az igazi. Ha ma nem tudja megnevezni az ERP-s kapcsolattartót, hónapokban tervezzen, ne hetekben.

Ütemezett CSV- vagy XML-fájlokkal SFTP-n, ERP-oldali staging táblával, vagy olyan adatbázisnézettel, amelyet az ERP-szállító vagy a saját ERP-csapatuk épít és támogat; az alkalmazástáblák közvetlen olvasását általában nem engedik, és egy verziófrissítésnél el is törhet. Amit elveszít, az az azonnaliság: a késés annyi, amilyen ütemezést beállítanak, jellemzően műszakonként vagy éjszakánként. A visszaút ERP-oldali importfolyamatot igényel, felelőssel és szabállyal arra, hogy mi legyen a visszautasított rekordokkal.

El fognak térni, és nem az integráció dönti el, kinek van igaza. Az eltérés abból jön, hogy a könyvelések más-más időpontban történnek, a selejtet rögzítik az üzemben, de még nincs lekönyvelve, és mozgatnak anyagot mindkét rendszeren kívül is. Amit kap, az egy eseménynapló: az eltérés visszavezethető egy műszakra és egy rendelésre ahelyett, hogy leltárnál egyben jelentkezne. Éles indulás előtt nevezzenek ki egy felelőst az egyeztetésre, és határozzák meg annak gyakoriságát.

Ha az ERP nem érhető el, de a helyi szerver és a gyári hálózat működik, a már kiadott rendelések fennmaradnak a paneleken, és az operátorok tovább tudnak visszajelenteni. Ezek a visszajelentések a helyi adatbázisba íródnak, tehát újraindítás után is megvannak, és kimennek, amint az ERP újra válaszol. A gyakorlati korlát az, hogy a soha át nem adott rendeléseket nem lehet elindítani. Kérdezzék meg, hogy az utólag feladott könyvelések beeshetnek-e olyan időszakba, amelyet a pénzügy már lezárt.

Nem. A folyamattervező az űrlapokat, a jóváhagyásokat és a munka emberek közötti továbbítását digitalizálja, tehát a papíralapú eltéréskezelés és a tervezési változtatások jól átvihetők rá, de nem változtat azon, ahogyan az ERP árat képez, tervez vagy könyvel. Minden olyan lépés mögé, amelynek ERP-rekordot kell módosítania, továbbra is kell egy interfész. Ami valójában számítás, például az önköltségi szabályok, oda tartozik, ahol az az adat van.