Migracija podatkov med sistemi: postopek in tveganja

Kaj pomeni migracija podatkov med sistemi#

Migracija podatkov med sistemi je prenos podatkov iz enega informacijskega sistema v drugega, pri čemer je treba ohraniti njihov pomen, povezave in uporabnost v novem okolju. Najpogosteje gre za prehod med ERP, CRM, dokumentnim sistemom (DMS, ECM) ali drugo poslovno aplikacijo, kadar podjetje zamenja platformo, združi sisteme po prevzemu druge organizacije ali prenese poslovanje v oblak. Rezultat mora biti sistem, v katerem zaposleni najdejo iste podatke, iste zgodovine naročil in iste povezave med strankami, dokumenti in izdelki kot prej, le v drugačni strukturi in na drugačni infrastrukturi.

Migracija ni preprosto kopiranje datotek iz enega mesta na drugo. Podatki v izvornem sistemu so pogosto shranjeni v drugačni strukturi, z drugačnimi šifranti, oznakami polj in pravili vnosa kot v ciljnem sistemu. Preden se prenos sploh začne, je treba ugotoviti, kateri podatki so še aktivni in se dnevno uporabljajo, kateri so arhivski ter kateri niso več potrebni in jih ni smiselno prenašati. Ta odločitev neposredno vpliva na obseg dela, na trajanje priprave in na to, kako hitro bo novi sistem pripravljen za dnevno delo zaposlenih.

Za odločevalca je migracija predvsem projekt tveganja in odgovornosti, ne le tehnično opravilo za razvojno ekipo. Napačno prenesen podatek o stranki, dobavitelju, zalogi ali pogodbi lahko povzroči napačno fakturiranje, podvojena naročila, izgubljeno zgodovino komunikacije ali neusklajene evidence med oddelki. Posledice se pogosto pokažejo šele mesece po prehodu, ko jih je težje popraviti. Zato mora biti migracija načrtovana kot samostojen projekt z jasno določenim obsegom, odgovornostmi, roki preverjanja in merili za uspešen zaključek, ne kot stranski učinek uvedbe novega sistema.

Kdaj podjetje potrebuje migracijo podatkov#

Vprašanje, kdaj je migracija podatkov potrebna, se v praksi pojavi ob menjavi ključnega sistema, na primer ERP ali CRM, ob združitvi dveh organizacij, ob prehodu iz lokalne infrastrukture v oblak ali ob opuščanju sistema, ki ga ponudnik ne vzdržuje več. V vseh teh primerih obstoječi podatki ne izginejo sami od sebe, ampak jih je treba dejavno prenesti, preoblikovati in preveriti, sicer ostanejo ujeti v sistemu, ki ga podjetje ukinja.

Podobno potrebo zazna vodstvo, kadar se v podjetju podatki o strankah, dobaviteljih ali proizvodnji vodijo v več ločenih sistemih, ki niso povezani, in kadar to povzroča podvajanje vnosa, neskladne evidence ali dvome, kateri zapis je pravilen. Konsolidacija v en sistem zahteva, da se podatki iz vseh virov najprej pregledajo, uskladijo in šele nato prenesejo v skupno okolje. Brez tega koraka konsolidacija samo prestavi obstoječo zmedo v novo aplikacijo, ne da bi jo dejansko odpravila.

Migracija je potrebna tudi, kadar podjetje digitalizira postopke, ki so dolgo časa tekli ročno ali v preglednicah, in želi te podatke vnesti v strukturiran sistem z nadzorom dostopa, revizijsko sledjo in avtomatiziranim poročanjem. V javnem sektorju se podobna potreba pojavi ob uvedbi novega informacijskega sistema ali portala, kjer je treba prenesti evidence iz starejših, pogosto slabo dokumentiranih aplikacij. V obeh primerih je količina in kakovost obstoječih podatkov tisto, kar določa, kako zahteven bo projekt.

• menjava ERP-ja, CRM-ja ali dokumentnega sistema (DMS/ECM)
• združitev ali prevzem druge organizacije
• prehod iz lokalne infrastrukture v oblak
• ukinitev sistema, ki ga ponudnik ne vzdržuje več
• konsolidacija podatkov iz več ločenih sistemov v enega
• digitalizacija ročnih postopkov in preglednic
• uvedba novega portala ali informacijskega sistema v javnem sektorju

Postopek migracije po korakih#

Postopek migracije podatkov med sistemi se začne z analizo izvornih podatkov: kje so shranjeni, v kakšni strukturi, koliko jih je, kdo jih uporablja in katere povezave med zapisi obstajajo. Šele na podlagi te analize je mogoče določiti, kateri podatki se prenesejo v celoti, kateri se arhivirajo ločeno in kateri se ne prenesejo, ker niso več relevantni. Ta korak je pogosto podcenjen, čeprav od njega največ zavisi, ali bo prenos v naslednjih fazah potekal predvidljivo ali s presenečenji.

Sledi mapiranje polj med izvornim in ciljnim sistemom, kjer se za vsako polje določi, kam se prenese, kako se preoblikuje in kaj se zgodi, če vrednost manjka ali ne ustreza pravilom novega sistema. Vzporedno poteka čiščenje podatkov: odstranjevanje podvojenih zapisov, popravljanje očitnih napak in poenotenje šifrantov, na primer poimenovanj strank, izdelkov ali oddelkov, ki so se v izvornem sistemu vodila neenotno. Kakovost tega koraka neposredno določa, ali bo novi sistem od prvega dne vseboval zanesljive podatke ali pa bo napake zgolj podedoval.

Pred dejanskim prenosom v produkcijo se izvede testni prenos v ločeno testno okolje, kjer se preveri, ali so podatki prišli na pravo mesto, ali so povezave med zapisi ohranjene in ali sistem z njimi pravilno deluje. V testnem okolju se ne uporabljajo pravi osebni podatki, temveč testni ali anonimizirani nabori, kar zmanjša tveganje za nenamerno razkritje podatkov med preizkušanjem. Šele ko testni prenos pokaže pričakovane rezultate, se pripravi produkcijski prenos, ki mu sledi validacija v realnem okolju.

Zadnji korak je potrditev, da je migracija uspešno zaključena: naročnik ali imenovana skupina uporabnikov preveri vzorec podatkov po vnaprej dogovorjenih merilih, primerja število zapisov, ključne vrednosti in delovanje povezanih funkcij v novem sistemu. Šele po tej potrditvi se izvorni sistem lahko ustavi ali arhivira. Vsak korak postopka je smiselno dokumentirati, saj dokumentacija kasneje služi kot dokaz, kaj je bilo preneseno, kaj namerno izpuščeno in zakaj, kar je pomembno tudi za revizijo ali morebitno kasnejšo primerjavo podatkov.

• analiza izvornih podatkov in odločitev, kaj se prenese
• mapiranje polj med izvornim in ciljnim sistemom
• čiščenje in poenotenje podatkov
• testni prenos v ločeno testno okolje
• validacija rezultatov testnega prenosa
• produkcijski prenos podatkov
• prevzemno testiranje in potrditev zaključka

Ločena okolja in zakaj so pomembna#

Eno temeljnih pravil pri migraciji je ločevanje razvojnega, testnega in produkcijskega okolja. Razvojno okolje služi pripravi postopka prenosa in preoblikovanja podatkov, testno okolje preverjanju, ali postopek deluje tako, kot je bilo načrtovano, produkcijsko okolje pa je tisto, s katerim dnevno delajo zaposleni in stranke. Če se te ravni pomešajo, na primer če se testiranje izvaja neposredno na produkcijskih podatkih, se tveganje za nenameren izpad ali poškodbo podatkov bistveno poveča.

Prav tako velja pravilo, da se v testnem okolju ne uporabljajo pravi osebni podatki. Namesto tega se pripravijo testni ali anonimizirani nabori, ki po strukturi ustrezajo pravim podatkom, a ne razkrivajo dejanskih strank, zaposlenih ali poslovnih partnerjev. To je pomembno tako z varnostnega kot s pravnega vidika, saj zmanjša tveganje, da bi med razvojem ali testiranjem prišlo do nepooblaščenega dostopa do občutljivih podatkov ali njihovega uhajanja izven nadzorovanega okolja.

Vsaka sprememba postopka prenosa gre pred uvedbo v produkcijo skozi pregled in testiranje, enako kot vsaka druga sprememba programske opreme. To pomeni, da se postopek migracije ne izvaja enkrat in nepreverjeno, temveč se najprej preizkusi, po potrebi popravi in šele nato ponovi na pravih podatkih. Za naročnika to pomeni manj presenečenj ob prehodu, saj so morebitne napake odkrite in odpravljene v testnem okolju, ne šele takrat, ko že vplivajo na dnevno poslovanje.

Tveganja pri migraciji podatkov#

Osrednje tveganje pri migraciji je izguba ali poškodba podatkov med prenosom, na primer če se del zapisov ne prenese, če se pri preoblikovanju izgubijo povezave med njimi ali če se prepišejo novejši podatki s starejšimi. Tovrstne napake niso vedno takoj vidne. Zapis lahko izgleda popoln, a manjka mu povezava na naročilo, dokument ali stranko, kar se pokaže šele, ko nekdo poskuša to povezavo dejansko uporabiti pri vsakodnevnem delu.

Naslednje tveganje je neskladje formatov in pravil med izvornim in ciljnim sistemom: datumi, davčne številke, valute, šifranti izdelkov ali statusi dokumentov so lahko v enem sistemu zapisani drugače kot v drugem. Če se to ne odkrije pravočasno, se lahko podatki prenesejo tehnično uspešno, a vsebinsko napačno, kar odkrijejo šele uporabniki pri dnevnem delu, na primer pri izdaji računa z napačnim datumom ali pri poročilu, ki ne sešteva pravilno.

Tveganje predstavlja tudi prekinitev poslovanja med prehodom, če izvorni sistem preneha delovati, preden je ciljni v celoti pripravljen, ali če zaposleni v prehodnem obdobju ne vedo, kateri sistem je trenutno veljaven vir podatkov. To je še posebej občutljivo v proizvodnji, financah in naročanju, kjer tudi kratkotrajna nedostopnost pravilnih podatkov o zalogi, cenah ali plačilih neposredno vpliva na tekoče posle in na zaupanje strank ali partnerjev v poslovanje podjetja.

Zadnja pomembna skupina tveganj je organizacijska: če odgovornosti med oddelki niso jasno določene, lahko nihče ne prevzame potrditve, da so preneseni podatki pravilni, ali pa vsak oddelek preveri le svoj del in spregleda povezave med oddelki. Prav tako se tveganje poveča, če zaposleni niso pravočasno seznanjeni s spremembo in med prehodom še naprej delajo v starem sistemu, kar ustvari dve vzporedni, med seboj neusklajeni različici istih podatkov.

• izguba ali poškodba podatkov med prenosom
• pretrgane povezave med zapisi (naročila, dokumenti, stranke)
• neskladje formatov, šifrantov in pravil med sistemi
• podvajanje zapisov
• prekinitev poslovanja med prehodom
• nejasna odgovornost med oddelki za potrditev pravilnosti
• vzporedno delo v starem in novem sistemu

Kako zmanjšati tveganja pri migraciji#

Tveganja pri migraciji podatkov se ne odpravijo z eno samo kontrolo, temveč z zaporedjem preverjanj, ki potekajo skozi celoten postopek. Prvi korak je natančna analiza izvornih podatkov pred prenosom, saj se večina napak, ki se kasneje odkrijejo v produkciji, dejansko skriva že v izvornih podatkih, na primer v podvojenih zapisih ali neusklajenih šifrantih. Čim prej se te napake odkrijejo, tem ceneje in hitreje jih je mogoče popraviti, preden vplivajo na nov sistem.

Drugi ključni ukrep je testiranje: ročno in avtomatizirano preverjanje prenesenih podatkov, testiranje API-jev in povezav med sistemi, regresijsko testiranje, da nova funkcionalnost ne pokvari obstoječe, ter prevzemno testiranje po vnaprej dogovorjenih merilih, ki ga izvede naročnik ali njegova ekipa. Pri zahtevnejših projektih je smiselno vključiti neodvisen QA, ločen od razvojne ekipe, ki je pripravila postopek prenosa, saj tak pregled pogosteje odkrije napake, ki bi jih razvijalec sam spregledal.

Tretji ukrep je postopnost: namesto enkratnega prehoda vseh podatkov in vseh oddelkov naenkrat je pogosto varneje najprej prenesti manjši, dobro nadzorovan del podatkov, preveriti delovanje in šele nato nadaljevati s preostankom. Vzporedno delovanje starega in novega sistema za krajše obdobje, s stalnim primerjanjem rezultatov, omogoča, da se morebitne razlike opazijo, preden se izvorni sistem dokončno ugasne in postane referenca za primerjavo nedosegljiva.

Lastništvo podatkov in odgovornosti#

Pri migraciji med sistemi je treba pred začetkom jasno določiti, kdo je lastnik podatkov in kdo nosi odgovornost za posamezen del postopka. Izvorna koda in podatki so last naročnika, ne izvajalca, kar pomeni, da mora naročnik ob zaključku projekta prejeti dostope, gesla in dokumentacijo, ki mu omogočajo, da sistem in podatke v celoti nadzoruje tudi po koncu sodelovanja z izvajalcem. To velja ne glede na to, ali je bila migracija izvedena v celoti interno ali z zunanjim partnerjem.

Poleg lastništva je treba določiti tudi projektnega vodjo, odgovornosti posameznih ekip, način komunikacije med naročnikom in izvajalcem ter obliko rednega poročanja o napredku. Pri projektih, ki segajo v več oddelkov, na primer kadar se podatki prenašajo hkrati za prodajo, finance in proizvodnjo, je pomembno, da vsak oddelek imenuje osebo, ki potrdi pravilnost svojega dela podatkov. Brez tega je tveganje, da bo potrditev migracije zgolj formalna, ne pa dejansko preverjena po vsebini.

Projekt migracije se lahko izvede v celoti ali po posameznih sklopih, na primer najprej podatki o strankah, nato podatki o zalogi in nazadnje finančne evidence. Ne glede na obseg velja isto pravilo: naročnik mora imeti ves čas jasen pregled nad tem, kaj je bilo že preneseno, kaj je v postopku in kaj še čaka na obravnavo, saj le tako lahko odgovorno odloča o nadaljnjih korakih in po potrebi prilagodi prioritete med samim izvajanjem.

Prevzem obstoječega ali nedokončanega sistema#

Pogosto se izvajalec vključi v migracijo, ko projekt ni začet na novo, temveč gre za prevzem obstoječega ali celo nedokončanega sistema, ki ga je začel drug ponudnik. V takem primeru je prvi korak vedno pregled: pregled izvorne kode, arhitekture, infrastrukture in obstoječih podatkov, preden se sploh oceni, kaj je mogoče nadaljevati in kaj je treba popraviti ali zgraditi znova. Ta pregled je nujen zato, ker vsaka nadaljnja odločitev, tudi tista o migraciji podatkov, temelji na tem, kaj je bilo dejansko že narejeno.

Prevzem nedokončanega sistema je za naročnika pogosto bolj tvegan kot začetek na novo, saj obstoječi podatki lahko že vsebujejo napake, nedokončane migracije ali delno preoblikovane zapise, ki jih je treba najprej razumeti, preden se nadaljuje. Zato pregled ob prevzemu ne sme biti zgolj tehnični, temveč mora vključevati tudi vprašanje, kateri podatki so trenutno veljavni, kateri so ostanki prejšnjega, opuščenega poskusa in kateri zapisi obstajajo vzporedno v več različicah brez jasnega odgovora, katera je pravilna.

Po pregledu izvajalec skupaj z naročnikom določi, ali se obstoječa migracija dokonča, popravi ali začne znova, in kaj od tega pomeni za že opravljeno delo prejšnjega izvajalca. Odločitev se sprejme na podlagi ugotovljenega stanja kode, arhitekture in podatkov, ne na podlagi splošne ocene. Za naročnika je pri tem ključno, da dobi jasno, dokumentirano razlago razlogov za izbrano pot, saj mu to omogoča razumeti, zakaj projekt morda traja dlje, kot je prvotno pričakoval.

Podpora po migraciji#

Migracija podatkov se s prehodom v produkcijo ne konča, saj se prve napake pogosto pokažejo šele, ko z novim sistemom dela cel oddelek ali celotno podjetje in ne le testna skupina. Zato je smiselno vnaprej dogovoriti, kdo v prvih tednih po prehodu spremlja delovanje, kako se prijavljajo napake in po kakšnem vrstnem redu se obravnavajo. Brez tega dogovora se lahko manjše napake kopičijo, dokler ne začnejo ovirati dnevnega dela več oddelkov hkrati.

V pogodbi o podpori je smiselno napake razvrstiti po razredih glede na resnost. Prvi razred zajema izpad, ko sistem ali njegov ključni del ne deluje in ima obravnava najvišjo prednost. Drugi razred je motnja, ko sistem sicer deluje, a posamezna funkcija ne, in se obravnava po dogovorjeni prednosti. Tretji razred je manjša napaka brez vpliva na poslovanje, ki se uvrsti v naslednjo objavo, četrti pa zahteva ali nadgradnja, za katero se oceni obseg in uskladi termin.

Poleg odprave napak lahko izvajalec po uvedbi prevzame tudi širši nadzor delovanja sistema, tehnične in varnostne posodobitve ter nadaljnji razvoj, na primer dodajanje novih funkcij, ki jih je naročnik med migracijo namerno odložil na kasnejšo fazo. Obseg te podpore se določi za vsak projekt posebej, saj se razlikuje glede na velikost sistema, število uporabnikov in kritičnost podatkov, ki jih sistem obravnava. Univerzalnih odzivnih časov, ki bi veljali za vse naročnike enako, ni, saj se ti določijo glede na kritičnost in dogovor.

• razred 1 – izpad: sistem ali ključni del ne deluje, najvišja prednost
• razred 2 – motnja: sistem deluje, posamezna funkcija ne
• razred 3 – napaka: manjša napaka brez vpliva na poslovanje, obravnava v naslednji objavi
• razred 4 – zahteva: sprememba ali nadgradnja, obseg se oceni posebej

Kako izbrati izvajalca za migracijo podatkov#

Pri izbiri izvajalca za migracijo podatkov je smiselno preveriti, ali zna razčleniti projekt na jasne faze: analizo, mapiranje, čiščenje, testni prenos, produkcijski prenos in podporo po uvedbi, ne le obljubiti, da bo »podatke prenesel«. Izvajalec, ki že v ponudbi opiše, kako bo preverjal kakovost prenesenih podatkov in kdo bo rezultate potrdil, kaže, da razume, kje v postopku nastajajo tveganja, ne le tehnične korake prenosa samega.

Drugo pomembno merilo je izkušnja s projekti, ki povezujejo več sistemov hkrati, na primer ERP, CRM in dokumentne sisteme, ter razumevanje, kako take povezave delujejo prek API-jev. Pri projektih v reguliranih panogah ali javnem sektorju je smiselno preveriti tudi, ali izvajalec pozna zahteve glede varnosti, revizijske sledi in skladnosti, saj te zahteve pogosto določajo, kako mora biti postopek migracije dokumentiran in kdo mora podatke potrditi, preden se prenos šteje za zaključen.

Epix in njegova specialistična partnerska mreža pri tovrstnih projektih sestavljata projektne ekipe iz senior inženirjev, arhitektov rešitev, podatkovnih strokovnjakov in QA inženirjev, glede na to, kateri sistemi se povezujejo in kako zahtevna je migracija. Znotraj te mreže je dostopen tudi kader s certifikati na področju oblačnih storitev, varnosti in projektnega vodenja, standardi upravljanja kakovosti in varnosti informacij pa so del delovanja delivery strukture, ne pridobitev posameznega podjetja v mreži.

Na koncu je smiselno preveriti, kako izvajalec obravnava vprašanje cene, saj natančna cena migracije brez predhodnega pregleda podatkov in sistemov ni realna ocena. Cena se določi po pregledu zahtev, obsega in tehnične zahtevnosti projekta, pri čemer krajša predhodna analiza obseg razčleni na sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno. Izvajalec, ki ponudi fiksno ceno pred takim pregledom, pogosto ne pozna dejanskega stanja podatkov, s katerimi bo moral delati.