Općenito o migraciji podataka
Migracija podataka označava proces kojim se podaci iz jednog informacijskog sustava prenose u drugi informacijski sustav, odnosno iz starog informacijskog sustava u novi sustav.
Pri tom procesu potrebno je, korištenjem različitih transformacija, podatke prilagoditi zahtjevima te podatkovnom modelu odredišnog sustava.
U nastavku je opisan konkretan slučaj migracije jednog dijela informacijskog sustava telekoma.
Zahtjevi projekta
Izvorišni sustav obuhvaća podatke o kupcima, podatke o uređajima i opremi te podatke o ugovorima, a kroz životni vijek je bio mijenjan u skladu s različitim poslovnim zahtjevima. Sustav je prilagođavan potrebama nastalim rastom i razvojem poslovnih procesa te same ponude usluga telekoma. Posljedica tih prilagodbi je različita kvaliteta podataka – ovisno o usluzi koju korisnik ima ili lokaciji na kojoj se nalazi.
Odredišni sustav koristi se za podršku poslovanju i sastoji se od SAP CRM i SAPR3 sustava koji zahtijevaju visoku razinu kvalitete podataka te njihovu strogu relacijsku usklađenost. Također je predviđen da bude jedinstven za više tvrtki koje se nalaze unutar grupacije, te je unificiranjem poslovnih procesa i poslovnih pravila potrebno uskladiti i podatke koji prate poslovanje. Temeljem takvih zahtjeva definiran je podatkovni model odredišne strane.
Na slici 1 prikazana je arhitektura sustava, tj. migracijskog rješenja. Na jednoj strani slike prikazan je izvorišni sustav, na drugoj odredišni sustav, dok se između njih nalazi tok i arhitektura migracijskog rješenja.
Slika 1. Arhitektura migracijskog rješenja
Analiza izvorišnog i odredišnog sustava
Početni, nulti, korak je određivanje opsega podataka koje je potrebno migrirati – npr. opseg je moguće odrediti statusom ugovora ili usluzi definiranoj na ugovoru, što stvara jasnu sliku o broju ugovora koje je potrebno migrirati. Na taj način utvrđuje se početna referentna točka pomoću koje je moguće odrediti broj ugovora koje logika može procesuirati, te ustanoviti gdje je još potrebno napraviti dodatne prilagodbe i transformacije.
U ovom koraku je vrlo važno istaknuti potrebu za stručnom osobom koja razumije kako organizaciju podataka na izvorišnom sustavu, tako i samo kvalitetu podataka, tj. njihovu manjkavost.
Ugovori koji trenutno (ili od nekog povijesnog trenutka) nisu aktivni ili ugovori koji imaju uslugu koja više nije relevantna izbačeni su iz promatranja te odmah, na početku, eliminirani iz migracije. Dodatnim analizama tijekom migracije pojavljuje se potreba za proširenjem početnog opsega, što će biti popraćeno dodavanjem novih uvjeta selekcije.
Općenito govoreći, čitav proces je iterativan te je potrebno više puta vraćati se unatrag i raditi dodatne prilagodbe logike selekcije podataka.
Prvi korak u procesu migracije jest analiza izvorišnog podatkovnog modela, gdje se definira u kojim se bazama, shemama i tablicama nalaze podaci koji se nalaze u opsegu migracije. Također, treba shvatiti kako su napravljena specifična procesna rješenja. Primjeri tih rješenja:
- dobivanje imena usluge spajanjem naziva pojedinačnih proizvoda koje korisnik koristi
- svrstavanje proizvoda u standardnu klasifikaciju koja se koristi u telekom poslovanju – paketi, tarife, naplatni proizvodi (eng. package, rate plan, billing product)
- identifikacija relevantnih datuma koji se pojavljuju na ugovorima (datum ostvarivanja prodaje, datum kreiranja naloga za aktivaciju, datum aktivacije usluge i sl.)
Rezultat analize su identificirane tablice, u kojima se nalaze podaci koji su predmet migracije, te su, korištenjem procesa ekstrakcije, transformacije i učitavanja (eng. ETL), prebačene na stage shemu baze podataka, kreiranu posebno za tu namjenu.
U samoj bazi se nalaze dvije sheme:
- stage shema gdje se nalaze podaci s izvorišnih sustava koji se dnevno osvježavaju. Na istoj shemi su prema potrebi kreirane pomoćne ili mapirajuće tablice
- produkcijska shema u kojoj se nalaze odredišne tablice, koje se pune transformiranim podacima
Na slici 2 prikazan je proces migracije.
Slika 2. Proces migracije
Svi ugovori, koji su unutar opsega migracije, podijeljeni su u segmente te je svaki od tih segmenata transformiran i obogaćivan podacima na sebi svojstven način.
Kriterij za segmentaciju bile su usluge, odnosno proizvodi i kombinacije proizvoda koje je korisnik ugovorio s telekomom. Korisnik koji ima samo jednu uslugu, npr. internet, pripada u jedan segment, dok onaj koji ima skup više usluga, npr. internet i telefoniju, pripada u neki drugi segment.
Ispravna segmentacija je važna zbog zahtjeva za unificiranom hijerarhijom – paketi, tarife, naplatni proizvod na odredišnoj bazi.
Na slici 3 prikazana je ilustracija hijerarhije proizvoda.
Slika 3. Hijerarhija proizvoda
Neke usluge koje su u izvorišnom sustave bile na najvišoj razini hijerarhije proizvoda, u odredišnom sustavu postale su dodaci nekim drugim proizvodima. Na primjer, „tarife“ koje su u izvorišnom sustavu bile tretirane kao paket, u odredišnom sustavu su postajale dodatne tarife nekog drugog paketa.
Takva poslovna pravila nalaze se u matičnim podacima.
Kreirane su mapirajuće tablice pomoću kojih je svaka usluga smještena na odgovarajuće mjesto u novoj hijerarhiji te joj je pridijeljeno novo ime.
Ugovori su pak razdvojeni na više sastavnih elemenata:
- zaglavlje ugovora
- zaglavlje ugovora s podacima o korisniku (adresni podaci)
- stavke ugovora – u kojima se nalaze detalji o uslugama koje korisnik ima, zajedno s vezanim opcijama (npr. popust u prva tri mjeseca)
- statusi ugovora
- datumi vezani za ugovor
- tehnički resurs vezan za uslugu (npr. modem vezan za uslugu internet, telefonski broj vezan za uslugu telefonija itd.).
Na ovaj način zadovoljen je zahtjev novog podatkovnog modela s njegovim entitetima i relacijama među podacima.
Osim uparivanja proizvoda prema matičnim podacima, također su profilirani adresni podaci, serijski brojevi opreme koja se nalazila na ugovorima, email adrese korisnika, dodavani su podaci koji su nedostajali, promijenjen je podatkovni tip, korigirana duljina znakova i slično. Sve s ciljem da ugovor postane kompletan, sa svim pripadajućim dijelovima.
Unošenje podataka u novi sustav
Prije unošenja podataka u odredišni sustav, sve je bilo potrebno, više puta, validirati od strane poslovnih korisnika i IT stručnjaka. To je napravljeno i kroz „migriranje“ podataka na testni odredišni sustav, na kojem je odrađeno korisničko testiranje, a koji je po svemu isti produkcijskom odredišnom sustavu.
Kako se radi o velikoj količini podataka, tako je postupak samog unosa u odredišni sustav odrađen iterativno. Prvo je generiran čitav ugovor (sa svim potrebnim dijelovima) te je zatim ubačen u odredišni sustav.
Sam unos podataka u novi CRM (fizički proces migracije) trajao je nekoliko dana. S obzirom na to da je poslovanje telekoma u međuvremenu i dalje teklo (na izvornom sustavu), postojala je mogućnost promjene samog ugovora tijekom procesa migracije (u odnosu na stanje ugovora pri početku migracije).
Te su promjene također prebačene na odredišni sustav, i to na sljedeći način: Podaci koji su migrirani u odredišni sustav su zapamćeni (u izvornom obliku, na stage shemi) te su uspoređivani s novim stanjem koje je nastalo u međuvremenu. Ako je uočena promjena, u drugoj iteraciji migrirani su samo promijenjeni ugovori, te novi ugovori koji su u međuvremenu nastali. Na taj način nije bilo potrebe za zaustavljanjem poslovanja (na period duži od jednog dana vikenda) te su sve promjene na ugovorima u potpunosti migrirane.
Zaključak
Tijekom čitavog procesa migracije podataka pojavljuju se nepredviđeni izazovi. Primjeri su iznimke u podacima nastale kao nedostatak kvalitete (slučajne prirode ili nastale zbog procesnih prilagodbi poslovanja). Zbog toga je potrebno, prilikom planiranja projekta, dodati vremensku rezervu koja će biti iskorištena upravo za rješavanje ovakvih primjera.
Važno je dokumentirati i vizualno popratiti način rješavanja tih izuzetaka jer postoji mogućnost da ih se s vremenom nakupi veći broj, čije će rješavanje znatno zakomplicirati proces migracije (moguće je da dorada zbog korekcije jednog podatka uzrokuje štetu na nekim drugim podacima). Zbog toga je nužno uz analizu specifičnih slučajeva zadržati i fokus na širu sliku cjelokupnog procesa.
Prilikom testiranja podataka potrebno je obratiti pažnju na to da se uzmu u obzir svi mogući poslovni i tehnički scenariji. Neprovjerena pretpostavka koja se pokaže pogrešnom uzrokuje još veće pogreške u relacijski ovisnim podacima.
Zahtjevi koje ovakav način izvedbe migracije mora zadovoljiti su mnogobrojni. Preporučuje se izrada kontrolnih upita za detekciju pogrešaka (npr. provjera je li narušen integritet podataka zbog duplih zapisa istovjetne opreme, na istom ugovoru – što je u suprotnosti s poslovnim procesom u telekomu).
Alati korišteni za migraciju su:
- Baza podataka – IBM Netezza SQL
- ETL alat – Informatica PowerCenter
Ova kombinacija alata omogućuje automatizaciju, dobru upravljivost procesa te testiranje (ponavljanjem loada dijela procesa ili čitavog procesa).
Sva logika migracije implementirana je u tok podataka (eng. data flow) u kojem je vidljiva međusobna zavisnost podataka (npr. prvo treba napuniti jedan segment ugovora te nakon toga segment koji je o njemu zavisan).
Kontrola kvalitete i validacija je ključna za uspjeh migracije, a uočeni nedostatci su glavna vodilja za praćenje tijeka migracije. Na temelju njih se rade korekcije na logici i podacima te se taj proces ponavlja dok se ne dobije rezultat koji zadovoljava zahtjeve kako projekta migracije tako i poslovanja kompanije.
Autor: Robert Režek
