Praktični vodič za arhitekturu rezidencije podataka

Za izradu finansijskog izveštaja, jedan kolega preuzima tabelu iz oblaka, drugi traži podatke iz ERP-a, a treći kopira podatke sa portala spoljnog partnera. Proces funkcioniše - sve dok se ne postavi pitanje: gde se tačno nalaze ovi podaci, ko ima pristup njima i šta se dešava ako neki sistem ili pružalac usluga ispadne?

Praktični vodič za arhitekturu rezidencije podataka ne odnosi se prvenstveno na geografsko postavljanje servera. Radi se o tome da skladištenje, obrada, prenos i obnova informacija važnih za poslovanje budu kontrolisani. U preduzećima sa 20-500 zaposlenih, ovo direktno utiče na kontinuitet poslovanja, pouzdanost izveštaja, poverenje partnera i rizike usklađenosti.

Šta je zapravo rezidencija podataka?

Rezidencija podataka se odnosi na to u kakvom geografskom, pravnom i operativnom okruženju se podaci fizički i logički nalaze. Nije dovoljno znati da aplikacija „radi u oblaku“. Važno je razjasniti u kom regionu se skladište primarni podaci, gde se prave sigurnosne kopije, kuda idu integracioni poruke i u kojoj zemlji radi podrška koja može pristupiti sistemu po potrebi.

Pitanje postaje posebno opipljivo kada webshop šalje podatke o narudžbini ERP-u, ERP prosleđuje informacije za fakturisanje, a zatim logistički partner dobija podatke potrebne za isporuku. Podaci jedne narudžbine mogu se pojaviti u više sistema, u više kopija i čak u više zemalja. Ako ovo nije svesno planirano, preduzeće zapravo ne zna sa sigurnošću gde upravlja svojim podacima.

Zato rezidencija podataka nije isključivo pravno ili informatičko pitanje. To je i operativno pitanje. Ako lokacija, vlasnik ili način obnove kritične informacije nisu jasni, tada se svakodnevno poslovanje oslanja na skriveni zavisni odnos.

Arhitektura rezidencije podataka: prvo mapirajte put podataka

Česta greška je što organizacija bira pružaoca usluga ili platformu oblaka pre nego što istraži tok podataka. To je kao da gradite novo skladište, a da ne znate koja roba, kojom učestalošću i odakle dolazi.

Dobar početak su neki ključni poslovni procesi. To može biti ispunjenje narudžbine, upravljanje radnim nalozima proizvodnje, fakturisanje, prenos podataka za obračun plata ili izrada izveštaja za menadžment. Za svaki proces treba razumeti odakle podaci potiču, ko ih menja, koji sistemi dobijaju kopije i gde se dugoročno čuvaju.

Nisu svi podaci podložni istoj zaštiti ili geografskom tretmanu. Javni katalog proizvoda, interni izveštaj o zalihama, ugovor i HR dokumenti sa ličnim podacima predstavljaju različite rizike. Previše stroga regulacija može nepotrebno poskupeti i usporiti operacije. Previše labav pristup može rezultirati nekontrolisanim pristupima i teško upravljivom usklađenošću.

Napravite popis podataka sa poslovnim odgovornim licem

Popis podataka nije tehnička tabela koju popunjava IT odeljenje. Za svaku važnu grupu podataka potreban je poslovni odgovorni, koji može reći zašto su podaci potrebni, koliko dugo ih treba čuvati, koji kvar bi izazvao poslovni problem i ko ih može koristiti.

Vredi zabeležiti tip podataka, primarni sistem, ciljne sisteme integracija, region skladištenja, lokaciju sigurnosnih kopija, vreme čuvanja i uloge pristupa. Ako informacija postoji u istom obliku u tri-četiri sistema, to takođe treba zabeležiti. Duplikacija nije uvek greška: može biti potrebna zbog dostupnosti, performansi ili zakonskog čuvanja. Ali svaka kopija treba da ima razlog i vlasnika.

Odluke neka vode rizik i operativne potrebe

Retko postoji jedno rešenje za sve u odlučivanju o rezidenciji podataka. Za preduzeće koje posluje isključivo sa domaćim sistemima može biti opravdano da određeni podaci ostanu na infrastrukturi u Srbiji. E-trgovinska kompanija koja prodaje u više zemalja može imati potrebu za obradom u više regiona zbog performansi, korisničke podrške ili partnerskih razloga.

Suština je da odluka bude dokumentovana. Menadžment treba da razume za koje podatke je zahtevana određena geografska regija, za koje je prihvatljivo drugo mesto i koje kontrole smanjuju rizik. Takve kontrole mogu biti enkripcija, strogi pristup zasnovan na ulogama, logovanje, redovno preispitivanje dozvola i testirani plan obnove.

Geografska lokacija sama po sebi ne pruža sigurnost. Sistem koji se skladišti lokalno može biti rizičan ako više ljudi koristi zajednički administratorski nalog, nema probnih kopija ili su dnevnici pristupa nejasni. Isto tako, pravilno dizajnirano, regulisano okruženje oblaka može biti kontrolisano rešenje ako je organizacija svesna granica odgovornosti.

Razdvojite primarne podatke, kopije i sigurnosne kopije

Mnogi problemi sa operativnom sigurnošću proizlaze iz nemogućnosti preduzeća da razlikuje ova tri pojma. Primarni podaci su verodostojan izvor iz kojeg počinje svakodnevno poslovanje. Kopija može biti primerak stvoren zbog integracije u drugom sistemu. Sigurnosna kopija nije za svakodnevni rad, već za obnovu.

Ako ERP smatra finansijske podatke verodostojnim, ali se menadžerski izveštaj pravi iz ručno ažurirane tabele, tada tabela ne može tiho postati drugi izvor istine. U tom slučaju prvo treba urediti proces izveštavanja: zašto je potrebna ručna kopija, koji podaci nedostaju u ERP-u i iz kog sistema izveštaj treba automatski da se generiše?

Ovo je jedan od manje vidljivih, ali važnih delova arhitekture rezidencije podataka. Ne reguliše samo gde se podaci nalaze, već i u koje podatke se može verovati.

Integracije su često skriveni putevi podataka

Na listi sistema preduzeća obično se nalaze ERP, CRM, webshop, sistem fakturisanja i skladišni sistem. Manje su vidljivi kritični međuelementi u pogledu protoka podataka: integracione usluge, e-mail eksporti, automatizovani prenosi fajlova, eksterni alati za izveštavanje i razvojna test okruženja.

Na primer, podaci o narudžbini iz webshopa mogu proći kroz integracionu platformu, ući u dnevnik grešaka, a zatim se pojaviti u e-mail obaveštenju. Ako narudžbina sadrži lične ili poslovno osetljive podatke, svi ovi putevi su deo arhitekture. Nije dovoljno proveriti gde webshop i ERP rade.

Zato je preporučljivo za svaki važan interfejs ispitati koji podaci prolaze kroz njega, da li se privremeno skladište, koliko dugo ostaju, kako se greške obrađuju i ko vidi dnevnike. Loše podešen izveštaj o greškama može godinama čuvati podatke koji više nisu potrebni za operacije.

Planirajte za prekide, ne samo za normalno funkcionisanje

Prava vrednost odluka o rezidenciji podataka vidi se u slučaju greške. Šta se dešava ako primarni region nije dostupan? Koliko gubitka podataka je prihvatljivo? Koliko vremena je potrebno da se obnovi obrada narudžbina, proizvodni podaci ili fakturisanje?

Ovo nisu isključivo tehnička pitanja. Ako skladište četiri sata ne vidi narudžbine koje treba ispuniti, kakvo kašnjenje, prekovremeni rad ili pritužbe kupaca to izaziva? Ako proizvodnja jedan dan nema pristup tehničkoj dokumentaciji, može li raditi bezbedno? Ciljeve obnove treba izvesti iz ovakvih poslovnih posledica.

Sigurnosna kopija pruža zaštitu samo ako se može obnoviti. Redovna proba obnove stoga nije administrativni teret, već validacija. Pokazuje da li je dokumentacija stvarna, da li su dozvole dostupne i da li preduzeće zaista može da pokrene kritične sisteme.

Ne tretirajte kao jednokratni projekat

Novi partner, nova zemlja, novi webshop, akvizicija ili zamena starog sistema mogu promeniti put podataka. Jednom napravljena arhitektura brzo zastareva ako nema upravljanja promenama.

Pre svake značajnije implementacije sistema ili integracije, neka bude jednostavna, ali obavezna kontrolna tačka: koje podatke nova rešenja obrađuju, gde ih skladište, kome daju pristup, koji dodatni pružaoci usluga učestvuju i kako se uklapaju u plan sigurnosnih kopija, logovanja i obnove. Ovo ne mora nužno usporiti razvoj. Sprečava kasnija iznenađenja, ručne zaobilaznice i skupe prepravke.

Dobra arhitektura rezidencije podataka nije vidljiva po broju dokumenata koji se o njoj prave. Vidljiva je po tome što menadžer može brzo dobiti odgovor o kritičnoj grupi podataka: gde se nalaze, ko je odgovoran za njih, ko ima pristup, šta je povezano sa njima i šta se dešava ako primarni sistem nije dostupan. Ako se na ova pitanja danas odgovara tek nakon konsultacija sa više ljudi, više tabela i dugih e-mail prepiski, vredi početi sa mapiranjem puta podataka.