Студија случаја интеграције система у веб продавници

Neko svakog jutra otvara administrativni panel webshopa, preuzima nove narudžbine, a zatim ih prebacuje u poslovni sistem. Nakon toga proverava zalihe u posebnoj tabeli, šalje listu nedostataka magacinu i ispravlja redove gde se podaci razlikuju. Do kraja ovog procesa, već su stigle nove narudžbine. Ova studija slučaja sistemske integracije nije priča o timu koji loše radi. Naprotiv, radi se o zaposlenima koji pokušavaju da učine postojeći proces funkcionalnim dok kompanija prerasta taj proces.

Sledeći primer prikazuje tipičan, anonimizovan rastući komercijalni proces. Pouka nije da je za svaki problem rešenje novi sistem ili potpuna zamena ERP-a. Suština je da prvo treba razumeti gde se prekida put informacija i zašto ljudi popunjavaju vezu između sistema.

Studija slučaja sistemske integracije: kada narudžbine putuju ručno

Kompanija je prodavala hiljade proizvoda putem sopstvenog webshopa i nekoliko partnerskih kanala. Webshop, program za fakturisanje i magacinska evidencija funkcionisali su sami za sebe. Problem je bio u onome što se dešavalo između njih.

Podaci o narudžbinama su se dva puta dnevno prebacivali u poslovni sistem. Informacije o zalihama su se vraćale u webshop sa zakašnjenjem, pa se dešavalo da proizvod koji je već rasprodat ostane dostupan za kupovinu. Pre fakturisanja, kolege su ručno proveravale podatke o kupcima, način isporuke i narudžbine sa plaćanjem pouzećem. Ako bi kupac promenio adresu, ta promena bi često bila zabeležena samo u jednom sistemu.

Prvo pitanje menadžmenta bilo je razumljivo: da li da automatizujemo obradu narudžbina? Pravo prvo pitanje, međutim, bilo je drugačije: zašto je potrebno proveriti istu narudžbinu tri puta i koji sistem je pouzdan izvor podataka?

Ova razlika je ključna. Ako tehnički povežemo neuređen proces, integracija će samo brže prenositi greške. Pogrešna logika zaliha, nepotpuni podaci o artiklima ili nejasna odgovornost neće se rešiti time što će prenos podataka biti automatski.

Istraživanje nije počelo sa interfejsima

Tokom mapiranja procesa, nisu prvo gledali koje API-je sisteme imaju. Pratili su šta se dešava od trenutka kada narudžbina stigne do pakovanja i slanja, pa sve do izrade fakture i izveštaja.

Ispostavilo se da značajan deo ručnog rada nije bio unos podataka, već upravljanje rizikom. Zaposleni su proveravali svaku narudžbinu jer nisu verovali u podatke o zalihama. Vodili su posebnu tabelu o problematičnim stavkama jer u magacinskom sistemu nije bilo lako filtrirati narudžbine koje čekaju delimičnu isporuku. Komunicirali su putem e-maila sa finansijama jer status povraćaja nije bio dosledno vraćen u sistem za upravljanje klijentima.

Istraživanje je razjasnilo četiri odluke. Webshop je postao izvor prijema narudžbina, poslovni sistem je bio zadužen za fakturisanje i finansijske statuse, a magacinski sistem za stvarne zalihe i ispunjenje. Takođe, trebalo je definisati kada se narudžbina smatra obradivom, kako se upravlja nedostatkom zaliha i ko je ovlašćen da stvara izuzetke.

Ovo je manje spektakularan posao od pokretanja nove integracije, ali ovde se odlučuje koliko izuzetaka će kasnije biti potrebno ručno ispraviti. Dobar sistemski odnos nije dobar zato što prenosi mnogo podataka, već zato što svi uključeni vide isto poslovno stanje.

Gde pripadaju podaci?

Većina problema sa integracijom leži iza jednostavnog, ali neodgovorenog pitanja: ako se isti podaci pojavljuju u više sistema, koji su validni?

U ovom slučaju, naziv proizvoda i marketinški opis mogli su ostati u webshopu, ali zalihe, status nabavke i mogućnost isporuke bili su povezani sa magacinskim operacijama. Podaci o fakturisanju i statusu plaćanja vraćali su se iz poslovnog sistema. Nije bilo potrebno kopirati svako polje svuda. Samo ona koja su imala poslovnu ulogu na tom mestu.

Ovo je smanjilo broj sukoba podataka i učinilo rešavanje grešaka jasnijim. Ako su zalihe pogrešne, kolega iz webshopa ne mora da istražuje u tri sistema. Postaje vidljivo gde je došlo do odstupanja i ko je odgovoran za ispravku.

Rešenje: ciljana veza, ne potpuna zamena sistema

Nakon procene, nije uveden novi sistem upravljanja preduzećem. Postojeći sistemi su još uvek podržavali osnovne poslovne potrebe, a potpuna zamena bi predstavljala neopravdan rizik, trošak i operativno opterećenje.

Umesto toga, sloj za integraciju između sistema je upravljao prenosom podataka o narudžbinama, zalihama i statusima. Ovaj sloj je proveravao obavezna polja, beležio kretanje podataka i izdvajao slučajeve koji su zahtevali ljudsku odluku. Na primer, nepoznat broj artikla ili nejasan način isporuke nisu tiho nestajali u procesu. Sistem je davao signal greške, a određeni zaposleni je video zadatak u upravljivoj listi izuzetaka.

Integracija nije odmah puštena u rad. Prvo su testirani podaci o statusima narudžbina, PDV stopama, popustima, delimičnim isporukama i storniranim dokumentima. Zatim je pokrenuta sa užim asortimanom proizvoda, a potom postepeno sa celokupnim prometom.

Postepeno uvođenje nije bilo usporavanje, već zaštita poslovanja. U procesu narudžbine, gubitak podataka, dvostruko fakturisana stavka ili pogrešno prikazana zaliha direktno utiču na klijenta. Zato je uz puštanje u rad postojala mogućnost povratka, beleženje, sistem ovlašćenja i jasna procedura za rešavanje grešaka.

Šta je sistemska integracija promenila u svakodnevnom radu?

Najupadljiviji rezultat nije bio samo to što je bilo potrebno manje ručnog unosa podataka. Jutarnje kopiranje narudžbina je prestalo, ali još važnije je bilo to što zaposleni nisu započinjali dan tražeći odstupanja od prethodne večeri.

Magacin je brže dobijao listu narudžbina za obradu. Korisnička služba je videla isti status narudžbine i ispunjenja kao i logistika. Finansijama nije bilo potrebno da traže posebne liste za povraćaje. Menadžment je dobijao izveštaj koji nije bio sastavljen od spajanja više fajlova svake nedelje.

Merljivi efekat se razlikuje od kompanije do kompanije, pa nije preporučljivo unapred obećavati opšte procente. U ovakvim situacijama, međutim, obično se smanjuje vreme posvećeno ručnoj proveri, manje je ispravki zbog grešaka u unosu i brže se obrađuju narudžbine. Manje kvantifikabilna dobit takođe je značajna: poslovanje se ne oslanja na sećanje i dnevnu pažnju jednog iskusnog čoveka.

Šta nije vredno automatizovati

Nije potrebno eliminisati svaki izuzetak. Narudžbina velike vrednosti sa posebnim uslovima isporuke ili sumnjiva situacija sa plaćanjem može opravdati ljudsko odobrenje. Cilj nije da svaka odluka bude mašinska, već da sistem prepozna šta je normalan poslovni proces, a šta zaista zahteva pažnju.

Zato su u integraciji ostale svesne kontrolne tačke. Narudžbine koje premašuju limit za plaćanje pouzećem, nepotpuni podaci o adresi i određeni slučajevi nedostatka zaliha bili su predmet revizije. Razlika je bila u tome što zaposleni nisu proveravali svaku narudžbinu, već samo one gde je za to postojao poslovni razlog.

Šta treba prepoznati u sopstvenom poslovanju?

Projekat sistemske integracije je opravdan kada problem nije greška jednog čoveka ili privremeni organizacioni poremećaj, već ponavljajući obrazac poslovanja. Takav znak je kada se isti podaci vode na više mesta, kada odeljenja razmenjuju informacije putem e-maila koje bi trebalo da se pojave u sistemu ili kada izrada nedeljnog izveštaja za menadžment traje satima.

Dubina rešenja zavisi od toga koliko su stabilni postojeći sistemi, kakav je kvalitet podataka i koliko izuzetaka proces obrađuje. Negde je dovoljno nekoliko dobro definisanih veza podataka. Drugde je potrebno prvo urediti podatke o artiklima, odgovornosti ili magacinske procese. Tek tada tehnološka odluka može biti trajno dobra odluka.

Ako u rastućoj kompaniji zaposleni redovno deluju kao ljudi između dva sistema, to ne znači nužno da je potrebno više ljudi. Često to ukazuje da je vredno ispitati sam put informacija - pre nego što sledeći korak rasta unese još više ručnog rada u poslovanje.