ERP integracija i digitalizacija tokova procesa

SAP, Dynamics, NetSuite, Odoo i mnogi regionalni ERP sistemi preko standardnih konektora; sve ostalo preko REST API-ja ili razmene fajlova.

Integracioni sloj mapira prilagođena polja i logiku. Prilagođavanje je uobičajeno i ne predstavlja prepreku.

MSF dopunjuje ERP. Finansije i komercijalu zadržavate tamo gde jesu, a dobijate sloj za upravljanje proizvodnjom.

Ka pogonu idu radni nalozi, matični podaci artikala, sastavnice, tehnološki postupci i stanja zaliha. Nazad u ERP idu potvrde naloga i operacija, proizvedene i škartirane količine, utrošak materijala i rezultati kontrole kvaliteta. Rasprava se uvek vodi oko toga koji sistem je vlasnik kog polja i šta se dešava kada se isto polje menja na obe strane. Sam spisak je retko sporan. Dogovorite vlasništvo polje po polje pre nego što iko krene da piše mapiranje, jer je ta odluka skupa za ispravljanje.

Mora, ako potvrde treba da se knjiže nazad. Sve što kreira materijalno kretanje ili zatvara operaciju jeste upis, a vaš ERP tim će tražiti da to ide kroz zvanično objavljene interfejse, BAPI, OData servise ili staging tabelu, nikada direktno u bazu. Prva faza samo za čitanje je sasvim razumna: povucite naloge, prikažite ih na terminalima u pogonu i knjižite ručno dok se brojevi ne poklope.

Nedeljama, ako sa ERP strane postoji imenovani čovek koji odgovara, test okruženje koje liči na produkciju, dogovoreni interfejsi i matični podaci koji su uglavnom tačni; duže, ako toga nema. Posao oko konektora retko je usko grlo, nego čekanje na termin za izmene, na odobrenje transporta i na nekoga ko će reći koji je od četiri šifre artikla pravi. Ako danas ne možete da imenujete osobu zaduženu za ERP, računajte u mesecima, ne u nedeljama.

Preko zakazanog slanja CSV ili XML fajlova na SFTP, preko staging tabele na ERP strani ili preko pogleda u bazi koji pravi i održava vaš dobavljač ERP-a ili vaš ERP tim; da vi sami čitate aplikativne tabele obično se ne dozvoljava i puca kod prve nadogradnje. Ono što gubite jeste trenutnost, a kašnjenje je onoliko koliki je interval koji zakažete, najčešće po smeni ili noću. Povratni smer traži import posao na ERP strani, sa vlasnikom i sa pravilom šta se radi sa zapisima koje odbije.

Neće se poklapati, i nijedna integracija ne presuđuje ko je u pravu. Razlike nastaju jer se knjiži u različitim trenucima, jer je škart evidentiran u pogonu a još nije proknjižen i jer se dešavaju kretanja mimo oba sistema. Ono što dobijate jeste trag događaja, pa se razlika može pratiti do konkretne smene i naloga, pre nego što ispliva kao gomila na popisu. Odredite ko radi usaglašavanje i kojom dinamikom, još pre puštanja u rad.

Ako je ERP nedostupan, a lokalni server i mreža u fabrici rade, već lansirani nalozi ostaju na terminalima i operateri normalno nastavljaju da potvrđuju. Te potvrde se upisuju u lokalnu bazu, preživljavaju restart i šalju se čim se ERP javi. Praktično ograničenje su nalozi koji nikada nisu ni preneti, njih ne možete startovati. Pitajte i šta se dešava ako naknadno poslata knjiženja padnu u period koji je računovodstvo već zatvorilo.

Ne može. Dizajner tokova procesa digitalizuje obrasce, odobrenja i prosleđivanje posla između ljudi, pa papirna odstupanja i proces inženjerskih izmena lepo prelaze na njega, ali ne menja to kako vaš ERP formira cene, planira ili knjiži, a svaki korak koji mora da ažurira zapis u ERP-u i dalje traži interfejs iza sebe. Logika koja je zapravo obračun, na primer pravila kalkulacije cene koštanja, pripada tamo gde ti podaci i žive.