Када корпоративна интеграција система доноси ред?

Porudžbina stiže u webshop, ali skladište saznaje o tome tek iz kasnije preuzetog spiska. Fakturisanje se pokreće u drugom sistemu, a podatke o zalihama neko ručno ispravlja kada ima vremena. Kada menadžer dobije nedeljni izveštaj, on je više istorijski dokument nego alat za podršku odlučivanju. Ovo je situacija u kojoj je integracija poslovnih sistema ne samo IT pogodnost, već uslov za operativnu kontrolu.

Problem retko leži u tome što kompanija ima previše sistema. Pre je u tome što ljudi prenose podatke između sistema: kopiraju, proveravaju, usklađuju, podsećaju druge, a zatim traže greške. Ovaj rad je često nevidljiv, ali od njega zavisi ispunjenje porudžbina, planiranje proizvodnje ili tačnost finansijskog zatvaranja.

Šta zapravo rešava integracija poslovnih sistema?

Cilj integracije sistema nije da se od svih aplikacija napravi jedan veliki sistem. U mnogim kompanijama to nema ni poslovnog ni tehničkog smisla. Dobro funkcionišući ERP, webshop, sistem za upravljanje skladištem, podrška proizvodnji ili fakturisanje mogu ostati pri svojim zadacima.

Integracija uređuje kako informacije teku između njih, koji sistem se smatra pouzdanim izvorom i koji događaj pokreće sledeći korak. Ako su podaci o zalihama proizvoda u ERP-u merodavni, onda ih webshop treba prikazati. Ako se u skladištu obavi komisioniranje, stanje treba da bude vidljivo i za upravljanje porudžbinama i za korisnički servis na vreme.

Ovo zvuči jednostavno, ali većina nesigurnosti nastaje upravo u ovim detaljima. Koji status znači da porudžbina zaista može biti predata kuriru? Šta se dešava ako spoljni sistem nije dostupan? Ko proverava stavke kod kojih je prenos podataka naišao na grešku? Funkcionalna integracija ne samo da šalje podatke. Ona upravlja odstupanjima, beleži događaje i jasno definiše odgovornost.

Prvo treba razumeti proces

Česta greška je da kompanija traži interfejs na prvi neugodan simptom. Porudžbine se prenose ručno? Povežimo webshop sa ERP-om. Izveštaj kasni? Izgradimo podatkovnu vezu. Ovo mogu biti opravdani koraci, ali sami po sebi ne garantuju poboljšanje.

Vredi prvo pratiti stvarni rad. Ne onako kako bi proces trebao da funkcioniše prema dijagramu toka, već kako ga kolege obavljaju na prosečan, a zatim problematičan dan. Ko dobija obaveštenje? Gde se vrši ručna provera? Koji podaci se unose na dva mesta? Koji izuzetak dovodi do toga da proces završi u e-mailu, telefonu ili posebnom spisku?

U veleprodajnom okruženju, na primer, možda prenos podataka o porudžbinama nije najveći problem. Možda porudžbina čeka jer odobrenje za jedinstveno određivanje cena nije jasno dodeljeno nikome. U proizvodnji, povezivanje proizvodnog plana i stvarnih podataka o mašinama ne pomaže mnogo ako je upotreba šifara artikala, jedinica ili kodova za otpad nekonzistentna.

Integracija ubrzava postojeće funkcionisanje. Ako je proces pogrešan ili nepotrebno složen, greška se takođe brže širi. Zato prvo korisno pitanje nije koje sisteme treba povezati, već koji podaci su potrebni za koju odluku i kada treba da budu dostupni.

Gde je najbolje početi?

Nisu sve veze jednako vredne. U kompaniji je obično najbolje početi tamo gde se susreću mnogo ponavljajućeg ručnog rada, značajan rizik od grešaka ili redovno operativno kašnjenje. Tipičan primer je prenos porudžbina iz webshopa u sistem upravljanja, sinhronizacija informacija o zalihama, vraćanje podataka o transportu ili prenos podataka o izvršenju prema fakturisanju.

Dobar prvi korak je dovoljno mali da ostane upravljiv, ali dovoljno važan da organizacija oseti promenu. To može biti da status porudžbine više nije prikazan u tri različita spiska ili da skladište ne radi iz e-mailova. Cilj nije nužno potpuna automatizacija. U mnogim slučajevima ispravno rešenje je da sistem pripremi podatke, a zaposleni ih proveri i odobri.

Ovo je posebno važno kod procesa punih izuzetaka. Kod jedinstvene proizvodnje, delimičnih isporuka, nepotpunih podataka o porudžbini ili cena vezanih za ugovor, ljudska odluka nije greška u sistemu. Zadatak sistema je da obezbedi informacije potrebne za odluku na jednom mestu, na pregledan način, i da ne zauzima dragoceni kapacitet administracijom.

Bez pitanja o vlasniku podataka nema kontrole

Jedan od najvažnijih, a često zanemarenih elemenata integracije poslovnih sistema je imenovanje vlasnika podataka. Ako se isto ime klijenta, proizvod, cena ili zaliha može menjati u više sistema, pre ili kasnije dolazi do odstupanja. U takvim slučajevima tehnička veza može savršeno funkcionisati, ali odluke se donose na osnovu pogrešnih podataka.

Za svaki kritični podatak treba razjasniti gde nastaje, ko ima pravo da ga menja, koji sistemi ga koriste i po kojem pravilu dobijaju promene. Ovo nije administrativna formalnost. Finansije, prodaja, skladište i IT treba da razumeju isto, na primer, pod rezervisanim zalihama ili zatvorenom porudžbinom.

Sinhronizacija u realnom vremenu nije uvek najbolji odgovor. Kod nekih procesa je opravdana, na primer kada trenutna prodajna zaliha webshopa predstavlja obećanje klijentu. U drugim slučajevima, zakazani, kontrolisani prenos podataka je sigurniji i jednostavniji za održavanje. Izbor treba da odredi poslovna posledica, a ne ono što je tehnički impresivnije.

Integracija je i zadatak upravljanja

Nakon završetka prenosa počinje rad koji odlučuje da li će biti koristan na duže staze. Sistemi se menjaju: dodaje se novo polje u webshop, menja se verzija ERP-a, menja se struktura podataka partnera ili počinje novi skladišni proces. Ako niko ne ispita njihov uticaj, prethodno stabilna veza može tiho proizvoditi greške.

Potrebni su proverljivi dnevnici, procedura za upravljanje greškama, prava pristupa i odgovorni. Pogrešne stavke ne smeju nestati u tehničkoj listi grešaka. Uključeni zaposleni treba da razume šta nije prošlo, koje poslovne posledice može imati i kako se može ispraviti. IT treba da vidi da li je greška u podacima, poslovnom pravilu ili problem sa pristupom sistemu izazvao odstupanje.

Upravljanje promenama takođe spada ovde. Pre uvođenja novog polja, statusa ili partnerskog odnosa, vredi odrediti testiranje i mogućnost vraćanja. Kritični procesi sa stanovišta proizvodnje, logistike ili fakturisanja ne mogu se tretirati isključivo iz perspektive programera. Poslovni tester može reći da li tehnički uspešan prenos zaista daje upotrebljiv rezultat. Kada ovo nije prvo rešenje?

Postoje slučajevi kada nije potrebna integracija, već sređivanje. Ako kompanija ne zna u kojem sistemu je ispravna baza proizvoda, ako proces nema vlasnika ili kolege različito tretiraju isti slučaj, nova veza samo će zabeležiti nesigurnost.

Slično, treba biti oprezan sa starim sistemima. Zastarela aplikacija može biti tehnički povezana, ali treba proceniti njenu podršku, dokumentaciju, bezbedno održavanje i očekivani životni ciklus. Ponekad je privremena veza podataka racionalna odluka. Drugi put je prvo potrebno modernizovati sistem ili proces.

U pristupu CGAT-a, zato, zadatak razvoja uvek prethodi mapiranju funkcionisanja. Ne da bi se napravio dugačak analitički dokument, već da bi kompanija tačno razumela gde nastaje gubitak, šta se menja intervencijom i kako će novo funkcionisanje ostati upravljivo.

Dobro osmišljena integracija na kraju nije vredna zbog broja povezanih sistema. Vredna je zato što porudžbina, kretanje zaliha ili proizvodni događaj prolaze kroz kompaniju sa manje nagađanja, manje ručne intervencije i jasnijom odgovornošću. Ako se ovaj cilj drži na umu, sledeća tehnička odluka će biti mnogo lakše doneta.

locale