ERP integracija bez dvostrukog unosa: šta se zaista sinhronizuje

„Sve unosimo dvaput“ je rečenica koju čujete u svakoj firmi koja ima više od jednog sistema. Roba se zavede u ERP, pa ponovo u prodavnicu. Kupac se otvori u CRM-u, pa opet u fakturisanju. Neko ceo dan prekucava ono što u drugom sistemu već postoji, greši, i onda se dva sistema polako razilaze. Prirodna reakcija je: hajde da to povežemo da ne kucamo dvaput.

To je tačna namera i pogrešna dijagnoza. Dvostruki unos je simptom. Bolest je što dva sistema oba veruju da su vlasnik istog podatka — i dok god oba misle da su u pravu, integracija samo ubrzava neslaganje. Pre nego što se išta poveže, mora se odgovoriti na jedno pitanje po svakom podatku: ko je ovde vlasnik.

Dvostruki unos je simptom, ne bolest

Kada dva sistema drže isti podatak a nijedan nije proglašen za merodavan, neslaganje nije mogućnost nego pitanje vremena. Neko promeni cenu u ERP-u i zaboravi u prodavnici. Neko ispravi adresu kupca u prodavnici, ERP i dalje šalje na staru. Svaka takva sitnica je mesto gde se dva sistema tiho razilaze, a razilaženje se ne primeti dok ne izazove pogrešnu isporuku ili pogrešan račun.

Povezivanje bez odluke o vlasništvu ne leči to — ono automatizuje razilaženje. Ako oba sistema smeju da menjaju istu cenu i oba to guraju jedan drugom, dobili ste petlju u kojoj poslednja izmena gazi prethodnu, bez ikoga ko zna koja je tačna. Zato prvi korak nije tehnički. Prvi korak je da se za svaki entitet imenuje sistem istine — jedan sistem koji je merodavan, dok svi ostali njegovu vrednost samo čitaju.

Sistem istine po entitetu

Greška je tražiti „glavni sistem“ za celu firmu. Ne postoji sistem koji je najbolji za sve. ERP najbolje zna nabavne cene i stanje glavnog magacina; prodavnica najbolje zna korpu i ponašanje kupca; skladišni sistem najbolje zna gde je koja paleta. Vlasništvo se dodeljuje po entitetu, ne po sistemu, i rezultat te odluke mora da postoji napisan negde gde ga svako može pogledati.

Ova tabela nije univerzalna — kod nekoga cene žive u prodavnici, kod nekoga kupci u ERP-u. Poenta nije koje polje je gde, nego da za svako polje postoji tačno jedan odgovor i da je taj odgovor zapisan. Svako polje bez imenovanog vlasnika je buduće neslaganje s odloženim dejstvom.

Praktično, ta odluka pripada dokumentu koji svi timovi vide, a ne usmenom dogovoru na sastanku. Kada za šest meseci neko doda novi kanal prodaje, prvo pitanje mora imati napisan odgovor: ko je vlasnik cene, ko zaliha, ko kupca. Bez tog papira, svaka nova integracija iznova otvara raspravu koja je jednom već rešena — i po pravilu je rešava drugačije nego prošli put.

Matični i transakcioni podaci se ne sinhronizuju isto

Sve što se sinhronizuje deli se u dve vrste, i mešanje njihovih pravila je čest izvor problema. Matični podaci su ono što stoji: artikli, kupci, cenovnici. Menjaju se retko, važe dugo, i sinhronizuju se u jednom smeru — od vlasnika ka svima koji čitaju. Transakcioni podaci su ono što se dešava: porudžbine, isporuke, uplate. Nastaju stalno, kratko su „aktuelni“, i traže sinhronizaciju po događaju.

Zbog toga katalog artikala i status porudžbine ne idu istom logikom. Katalog se može gurnuti jednom dnevno i niko neće primetiti; ako se status porudžbine kasni sat vremena, kupac zove da pita gde mu je roba. Kada NG Commerce preuzima katalog iz ERP-a, to je matična sinhronizacija u jednom smeru; kada šalje porudžbinu nazad, to je transakcioni događaj koji ne trpi kašnjenje.

Smer toka i zamka „poslednji upis pobeđuje“

Kada je vlasnik jasan, smer toka je očigledan: od vlasnika ka čitaocima, nikad nazad. Problem nastaje kod polja koja dva sistema oba smeju da menjaju — i tu se rađa najopasnije prividno rešenje, pravilo „poslednji upis pobeđuje“.

Zvuči razumno: ako stigne novija izmena, ona je tačna. Ali novije ne znači tačnije. Ako operater u skladištu ispravi stanje na osnovu fizičkog prebrojavanja, a pola sata kasnije automatski uvoz iz starog izveštaja vrati pogrešan broj, „poslednji upis“ upravo je pogazio jedini tačan podatak novijim pogrešnim. Sukob nije rešen — samo je sakriven ispod vremenske oznake.

Serijski ili u realnom vremenu

Ne mora sve da bude trenutno, i insistiranje da bude poskupljuje integraciju bez koristi. Trik je razdvojiti ono što zaista mora u realnom vremenu od onog što može serijski, jednom u nekoliko sati ili preko noći.

• Zaista realno vreme: stanje zaliha za nešto što se brzo rasproda, status porudžbine koji kupac prati, rezervacija robe u trenutku kupovine.
• Može serijski: katalog artikala, opisi, slike, cenovnici koji se menjaju retko, istorijski izveštaji.
• Zavisi od posla: cene, koje su serijske kod stabilnog asortimana a realne kod dnevnih promena i akcija.

Kada NG Operations planira proizvodnju na osnovu porudžbina, a KickOff WMS vodi fizičko stanje, zalihe moraju da putuju odmah, a matični podaci mogu da sačekaju noćni ciklus. Sve staviti u realno vreme znači platiti infrastrukturu koju devedeset posto podataka ne koristi.

Usaglašavanje: kako dokazati da se sistemi slažu

Integracija koja radi danas ne znači da će se sistemi slagati za mesec dana. Poruke se izgube, poslovi otkažu, neko ubaci ručnu izmenu mimo integracije. Bez redovne provere ne znate da se sistemi slažu — znate samo da još niko nije primetio da se ne slažu. Usaglašavanje je taj mehanizam provere.

1. Uporedite ukupne veličine. Broj artikala, zbir stanja, broj otvorenih porudžbina — brz signal da nešto grubo ne štima.
2. Uporedite stavku po stavku periodično. Ne pri svakoj poruci, nego u zakazanom ciklusu koji nađe tiha razilaženja.
3. Zabeležite razlike, ne samo brojku. Koji artikal, koje polje, koja vrednost sa svake strane — inače znate da greška postoji, ali ne gde.
4. Odlučite unapred šta je merodavno. Kada se razlika nađe, sistem istine za to polje rešava spor, bez rasprave svaki put.

Tabela preslikavanja koju niko ne želi

Postoji deo svake integracije koji svi žele da izbegnu, a niko ne sme: preslikavanje šifara. Jedinice mere, poreske stope, šifre artikala i partnera retko su iste u dva sistema. Jedan kaže „kom“, drugi „kom.“, treći „PCS“. Jedan drži poresku stopu kao oznaku, drugi kao procenat. Ta tabela preslikavanja mora da postoji, neko mora da bude njen vlasnik, i ona mora da se održava kada se pojavi nova šifra.

Tabela bez vlasnika trune. Pojavi se nova jedinica mere, niko je ne doda, i tiho počnu da propadaju baš one poruke koje je koriste — a niko ne zna zašto. Zato preslikavanje nije tehnički detalj nego stalna obaveza koja pripada nekome po imenu.

Isto važi za puštanje u rad. Migracija i redosled uključivanja se planiraju, ne improvizuju: prvo se uskladi katalog i šifarnici, pa se izjednače stanja u jednoj tački u vremenu, pa se uključi transakcioni tok, i tek onda se ugasi stari dvostruki unos. Ako vam predstoji ovakav posao, pogledajte kako pristupamo integracijama ili nas kontaktirajte s popisom sistema koje treba povezati — odluka o vlasništvu podataka donosi se pre prvog reda koda.