Razvoj općih zahtjeva za migraciju podataka
Kao dio razvoja ukupnih zahtjeva za migraciju podataka, poslovni analitičar mora definirati strategiju migracije podataka. Na osnovu potreba poslovanja, načina rada organizacije korisnika, treba odabrati migraciju „velikog praska“ ili glatku migraciju.
Prilikom odabira strategije „velikog praska“, mora se odrediti vrijeme koje preduzeće može potrošiti na zastoje tokom migracije podataka. Nakon određivanja količine vremena koje preduzeće može potrošiti na stanke tokom migracije podataka, može se sastaviti raspored migracije podataka. Prilikom zakazivanja migracije podataka, treba izdvojiti slobodan dan ili dane za ponovnu migraciju u slučaju ozbiljnih grešaka.
Prilikom odabira strategije glatke migracije, sve poslovne korisnike ciljnog sistema treba podijeliti u grupe za koje treba izraditi raspored prelaska na rad sa ciljnim sistemom. Nakon podjele poslovnih korisnika u grupe, moraju se definirati njihovi odgovarajući skupovi podataka i entiteta. Prilikom raspodjele poslovnih korisnika u grupe, odnosi ovih grupa moraju se uzeti u obzir u okviru poslovnog procesa koji je automatiziran u ciljnom sistemu.
Paralelno sa izborom strategije za sprovođenje migracije podataka, menadžment projekta i/ili poslovni analitičar treba da identifikuje tipične rizike migracije podataka. Za svaki identifikovani rizik mora se odabrati strategija (metode) upravljanja rizikom i razviti skup mjera za prevenciju rizika. Strategija izbjegavanja rizika može biti jedna od sljedećih:
Tabela 1 daje matricu tipičnih rizika migracije podataka i kako se nositi sa svakim od ovih rizika. Ćelije matrice daju primjere aktivnosti za bavljenje svakim od rizika u okviru svake metode prevencije rizika.
Prilikom sastavljanja tabele pretpostavljeno je da strategija „Odbijanje“ nije prihvatljiva za projektni tim, jer je preduslov za izradu studije potreba za obavljanjem migracionog posla. Dakle, ne postoji mogućnost potpunog ili delimičnog isključenja ovakvih radova iz delokruga projekta.
Tabela 1. Matrica rizika i moguće strategije za suočavanje sa rizicima u fazi migracije
|
Strategija upravljanja rizikom |
odbiti |
Broadcast |
Usvajanje |
|
|
Rizici izrade tehničke specifikacije |
Razrada zahtjeva za migraciju zajedno sa biznisom, vlasnicima i potrošačima migriranih podataka |
Uključivanje konsultanata u izradu tehničkih specifikacija |
Formiranje rezerve budžeta i vremena na projektu za rad sa potencijalnim zahtjevima za izmjenom |
|
|
Rizici testiranja |
Izrada testnih planova i scenarija koji uključuju poslovne korisnike |
Prenošenje testnog paketa u poseban tim sa unapred određenim uslovima za prihvatanje njihovih rezultata |
Formiranje rezerve vremena i budžeta za potencijal dodatni rad zbog nepotpunog testiranja softvera za migraciju i hostiranih podataka |
|
|
Rizici u procesu pribavljanja i učitavanja podataka |
Razrada zahtjeva za probni istovar. Provođenje "testne" migracije korištenjem probnog prijenosa |
Formiranje rezerve budžeta i vremena za ponovljeni prijem istovara i iterativnih preuzimanja |
||
|
Strategija upravljanja rizikom |
odbiti |
Broadcast |
Usvajanje |
|
|
Rizici povezani sa radom projektnog tima |
||||
|
Rizici postavljanja podataka u ciljni sistem |
Paralelni razvoj modela podataka „kao što jeste“ i „biti“ za nivelisanje razlika u formatima i metodama rada sa podacima u izvoru i destinaciji |
Formiranje rezerve vremena i budžeta za poboljšanja funkcionalnosti prijemnog sistema |
Organizacija planiranja migracije podataka
Ulaz za razvoj planova rada migracije je strategija migracije podataka formulisana kao dio razvoja ukupnih zahtjeva za migraciju podataka.
Rezultat planiranja rada migracije podataka trebao bi biti skup dizajnerskih artefakata koji bilježe slijed koraka za implementaciju migracije podataka. Rezultati faze planiranja su sljedeći projektni artefakti: plan rada migracije i komunikacijski plan za fazu migracije podataka.
Plan rada migracije definiše skup zadataka i odgovorne za njihovu implementaciju, distribuiranih pomoću RACI matrice. Plan rada projekta za migraciju treba da sadrži zadatke i radne pakete za svaku od faza migracije: od pripremne do post-migracione faze rada. Uzimajući u obzir rezultate analize projektnog iskustva, WBS je razvijen da izbjegne rizike i odgovara „referentnim“ teorijskim pristupima organizaciji migracije podataka.
Prikazano na sl. 3 radna struktura pokriva sve faze migracije i može se pratiti do linija plana rada projekta. Kao dio plana rada projekta, treba navesti rokove za implementaciju svakog zadatka i rezultate svakog zadatka. Prilikom izrade plana rada za svaki zadatak mora se definisati uslov čije ispunjenje će nedvosmisleno utvrditi da je zadatak završen.
Jednako važan artefakt dizajna faze migracije podataka je komunikacijski plan. Komunikacioni plan u fazi migracije definiše ciljeve i vrste interakcije između članova projektnog tima, kao i između članova projektnog tima i zaposlenih korisnika – poslovnih korisnika.
Dizajn komunikacijskog plana u fazi migracije trebao bi se zasnivati na ranije izrađenom planu rada. Za svaki zadatak unutar plana projekta treba definirati sljedeće atribute:
Ko bi trebao biti uključen u komunikaciju? Koje su grupe uloga?
Predložak za komunikacijski plan za fazu migracije podataka prikazan je u Tabeli 2 ispod (Tabela 2).
Tabela 2 Predložak komunikacijskog plana za fazu migracije podataka
|
Tema komunikacije |
označava glavni problem ili zadatak za koji je ova komunikacija neophodna, odjeljak zahtjeva za migracijom, objekte podataka |
|
Članovi projektnog tima |
grupe uloga i uloge su naznačene |
|
Potreba za interakcijom sa biznisom |
označeno sa da ili ne |
|
Učesnici sa poslovne strane |
naznačena je funkcionalna jedinica i odgovorni zaposlenik |
|
Vrsta interakcije |
vrsta interakcije je naznačena, na primjer: pismeno, sastanak, radionica |
Razviti i dokumentirati poslovne zahtjeve za migraciju podataka
Razvoj i dokumentovanje zahtjeva za migraciju podataka treba da se odvija u nekoliko faza. Kao dio metodologije koja se razvija, faza razvoja poslovnih zahtjeva za migraciju podataka će uključivati i korak provođenja i dokumentovanja rezultata ankete organizacije korisnika. Svrha faze razvoja poslovnih zahtjeva za migraciju podataka je razvoj kompletan paket zahtjevi za specijalizovanim softverom za migraciju podataka, kao i za sastav podataka migriranih u ciljni sistem.
1. Inspekcija operativnog informacionog sistema
Pregled operativnog informacionog sistema hronološki treba da bude prva faza rada u razvoju zahteva za migraciju podataka.
Ispitivanje postojećeg informacionog sistema kao dio razvoja zahtjeva za migraciju podataka može se provesti u sklopu poslovnog istraživanja cjelokupnog projekta implementacije IP. Istraživanje kao dio razvoja zahtjeva za migraciju podataka trebalo bi da ima za cilj kreiranje modela podataka 'kao što je'. Model podataka 'kao što je' omogućit će pripremu zahtjeva za sastav podataka koji se migriraju iz izvornog sistema na odredište. sistem.
Model podataka `kao što je' opisuje sve objekte podataka koji se koriste u operativnom sistemu.Nakon kompajliranja takvog modela, korisniku će biti lakše da odabere listu objekata podataka za prijenos u sistem koji prima.U takvom modelu , treba navesti nazive entiteta, opisati njihov sastav atributa i odnose između entiteta, ukazujući na njihovu kardinalnost.
Pored modela podataka operativnog sistema, u fazi anketiranja treba izraditi dijagrame poslovnih procesa koji koriste odabrane objekte podataka za prijenos u ciljni sistem. Modeli poslovnih procesa će vam omogućiti da identifikujete nedostajuće objekte podataka ako su propušteni prilikom analize modela podataka.
Pored sastavljanja modela podataka „kao što jeste“, u fazi istraživanja treba opisati pravila za rad sa rječnicima i priručnicima u operativnom sistemu, a posebno za svaki rječnik treba opisati sljedeće:
Format specifikacije zahtjeva za migraciju rječnika iz izvornog sistema u ciljni sistem dat je u tabeli i dat je primjer popunjavanja takve specifikacije.
2. Razvoj zahtjeva za profilom podataka za migraciju
Razvoj zahtjeva za profilisanje podataka za migraciju treba da uključi ključne grupe poslovnih korisnika u skladu sa komunikacijskim planom razvijenim tokom planiranja migracije podataka. Obrazac dokumenta i primjer popunjavanja za evidentiranje rezultata ankete prikazani su u Tabeli 4 (Tabela 4).
Poslovni korisnici su izvori za odgovore na sljedeća pitanja profila podataka za migraciju podataka:
Odgovor na ovo pitanje treba da bude opis objekata podataka izvornog sistema sa opisom karakteristika rada sa objektom podataka tokom vremenskog perioda za koji se podaci migriraju.
7) Koja funkcionalna jedinica ili određeni korisnici posjeduju podatke? Odgovor na ovo pitanje treba da bude tabela korespondencije između objekata podataka i zaposlenih korisnika.
IT odjel je izvor za odgovore na sljedeća pitanja o profilu podataka za migraciju:
IT osoblje i poslovni korisnici moraju raditi zajedno kako bi procijenili kritičnost potencijalnih grešaka prilikom prijenosa podataka iz izvornog sistema u ciljni sistem. Konkretno, poslovni korisnici i IT odjeli trebaju analizirati odnos objekata podataka na razini baze podataka koja se koristi za utvrđivanje liste mogućih provjera integriteta podataka prilikom migracije na ciljni sistem.
Razvoj zahtjeva za profil podataka za migraciju treba završiti pribavljanjem probnog učitavanja podataka iz izvornog sistema (izvornih sistema) u skladu sa razvijenim profilom podataka. Dobiveni testni prijenos će se koristiti za otklanjanje grešaka u softveru za migraciju i procjenu kvaliteta dostavljenih podataka.
Nakon izrade zahtjeva za profil podataka za migraciju, potrebno je razviti pravila za čišćenje ili transformaciju podataka preuzetih sa izvornih sistema radi njihovog pravilnog smještaja u ciljni sistem. U tu svrhu potrebno je povezati poslovne zahtjeve sa modelom podataka projektovanog sistema i opisom modela podataka sistema u radu.
Za potrebe određivanja nivoa kvaliteta podataka, sledeće vrste logičkih provera treba da se primenjuju unutar svakog migracionog objekta podataka:
Zahtjevi za logičke provjere trebaju biti dokumentirani u funkcionalnoj specifikaciji za uslužni program za migraciju podataka.
Identifikovane nedoslednosti u podacima za preuzimanje mogu se eliminisati na jedan od sledećih načina: podaci se mogu ukloniti iz otpremanja ako nemaju poslovnu vrednost ili konvertovati pomoću određenih algoritama.
Za ispravno postavljanje podataka u ciljni sistem, za objekte podataka mogu se razviti algoritmi transformacije sljedećih tipova:
Zahtjeve za algoritme za čišćenje i transformaciju podataka, kao i tipove objekata podataka za koje će se primjenjivati, treba fiksirati u funkcionalnoj specifikaciji za uslužni program za migraciju podataka.
2) Zahtjevi za imenovanje subjekata u prijemnom sistemu
Zahtjeve za razvoj algoritama za imenovanje entiteta u odredišnom sistemu treba razviti u slučaju da u ciljnom sistemu nije moguće primijeniti algoritme koji se koriste za imenovanje entiteta u izvornom sistemu/sistemima.
Algoritme za imenovanje i numeriranje objekata podataka treba razviti u sljedećim slučajevima:
Zahtjevi za algoritme za generiranje imena i brojeva migriranih entiteta trebali bi biti fiksirani u funkcionalnoj specifikaciji za uslužni program za migraciju podataka.
3) Zahtjevi za evidentiranje migracije podataka
Da bi pratili status procesa migracije podataka, uslužni program za migraciju mora podržavati evidentiranje učitavanja podataka na ciljni sistem. Istovremeno, dnevnik uslužnog programa za migraciju treba da odražava informacije o svim izvršenim logičkim provjerama i brisanju podataka iz skupa podataka za učitavanje u ciljni sistem.
Zahtjevi za dnevnik alata za migraciju trebaju biti dokumentirani u funkcionalnoj specifikaciji za alat za migraciju.
Dnevnik uslužnog programa za migraciju trebao bi biti u stanju pratiti svaku operaciju kao dio procesa učitavanja podataka u ciljni sistem.
Svaki unos dnevnika migracije podataka mora imati najmanje sljedeći skup atributa:
Atribut Error Description odražava parametriziranu poruku uslužnog programa za migraciju podataka ako uslužni program za migraciju nije mogao učitati objekt podataka u ciljni sistem.
Ako je za objekt podataka postavljena zastavica - objekt je uklonjen iz migriranih podataka, tada bi atribut "Razlog izuzetka za brisanje objekta podataka" trebao odražavati parametriziranu poruku koja opisuje algoritam čišćenja podataka prema kojem je ovaj objekt obrisan iz migrirani podaci.
Fragment dnevnika uslužnog programa za migraciju dat je u Dodatku 4 (Dodatak 4 - Fragment dnevnika uslužnog programa za migraciju).
Testiranje kao dio rada na migraciji podataka
Testiranje se sastoji od sljedećih radnih paketa:
Ispod je niz koraka koje mora poduzeti projektni tim kako bi izvršio svaku od faza testiranja.
Inicijalno testiranje softvera za migraciju trebalo bi da identifikuje i eliminiše tehničke kvarove i nedostatke u razvijenom uslužnom programu za migraciju. Takvo testiranje treba da sprovede testni tim u skladu sa razvijenim test slučajevima. Istovremeno, nakon poboljšanja softvera, u slučaju identifikovanih grešaka, obavezno je izvršiti regresijsko testiranje uslužnog programa.
Poslovno testiranje softvera za migraciju na usklađenost sa poslovnim zahtjevima i algoritmima za transformaciju podataka trebalo bi da se izvrši korištenjem dnevnika uslužnog programa za migraciju kako bi se osigurala potpunost provjera i testova. Procedura za poslovno testiranje može biti sljedeća:
Greške zabeležene tokom testiranja treba da se evidentiraju na način da je moguće nedvosmisleno utvrditi izvor njihovog nastanka – algoritam ili pravilo koje je neispravno radilo.
Za poslovno testiranje uslužnog programa za migraciju mogu se koristiti automatizirani alati za testiranje. U njihovom nedostatku, skup jediničnih testova treba da pokrije sve moguće tipove objekata podataka koji su migrirani u ciljni sistem, kao i sve provjere i mehanizme transformacije dizajnirane za svaki tip.
Testno čišćenje i učitavanje podataka podrazumeva rad sa podacima dobijenim nakon razvoja paketa zahteva za profil migriranih podataka. Testni prijenos bi trebao biti alat za testiranje sljedećih karakteristika softvera za migraciju:
Rad sa testnim učitavanjem je završna faza testiranja softvera za migraciju. Nakon obrade testnog učitavanja od strane uslužnog programa za migraciju, postaje moguće procijeniti potrebno planirano vrijeme za preuzimanje cijelog niza migriranih podataka. Uspješno postavljanje probnog upload-a na ciljni sistem treba da znači interno prihvatanje uslužnog programa za migraciju i mogućnost prelaska na posao preuzimanja produkcije – puni upload sa izvornog sistema na ciljni sistem.
Probno čišćenje i učitavanje podataka u ciljni sistem uključuje izvođenje svih operacija neophodnih za migraciju podataka na ciljni sistem, uključujući testiranje funkcionalnosti ciljnog sistema. Ova faza testiranja je detaljnije opisana u nastavku.
Testiranje funkcionalnosti odredišnog sistema trebalo bi pružiti priliku za provjeru da sve sistemske funkcije koje koriste migrirani sadržaj rade kako se očekuje. U ovom slučaju, takvo testiranje se može provesti u dvije faze:
Da bi se testiralo zdravlje prijemnog sistema, odmah po završetku pokretanja, treba napisati kratku test skriptu koja pokazuje šta tačno treba testirati radi operativnosti, na primer:
Detaljno testiranje funkcionalnosti prijemnog sistema podrazumeva pokretanje svih automatizovanih poslovnih procesa za koje se migriraju ulazni podaci. Ako učitani podaci uključuju više od jedne vrste objekata podataka, tada se moraju osigurati testne skripte za svaki migrirani tip podataka. Rezultate testiranja funkcionalnosti sistema prijemnika treba zapisati u dnevnik testiranja.
U skladu sa ANSI standardom, dnevnik testiranja migracije podataka (log) treba da ima sljedeću strukturu:
Opis operacije unutar testnog slučaja mora uključivati:
a) Ulazni podaci za operaciju;
b) Očekivani rezultati;
c) Dobijeni rezultati;
d) datum i vrijeme operacije;
e) Broj pokušaja izvođenja operacije;
f) Članovi projektnog tima odgovorni za testiranje;
g) Operativno okruženje unutar test slučaja.
Fragment dnevnika za testiranje funkcionalnosti prijemnog sistema dat je u Dodatku 5 (Prilog 5 - Dnevnik testiranja rezultata migracije).
Prelazak na besplatni softver je poput migracije na noviji operativni sistem. Kao primjer možemo navesti pojavu prvih verzija Windows-a u našoj zemlji. Jednako upečatljiv primjer je migracija na Windows NT, ideologija rada u kojoj se oštro razlikovala od Windowsa 9x. Možemo navesti još jedan primjer - svaka nova verzija MS Office paketa razlikuje se od prethodne ne samo po razlikama u interfejsu, već i po formatima datoteka. Dakle, zadatak migracije je relevantan čak iu slučaju kada se koristi softver jednog proizvođača.
Ovaj članak nudi opći opis metodologije migracije s naglaskom na bitne točke. Opšti princip migracije je promišljena, pažljiva implementacija procesa kroz postepene promjene. Migracija se sastoji od nekoliko logički integralnih sekcija, faza.
stvaranje radne grupe (ko radi)
Prilikom implementacije migracije potrebno je predvidjeti rješavanje pitanja tehničke i netehničke prirode.
Važno je uzeti u obzir pravne probleme koji su u posljednje vrijeme postali izuzetno aktualni za neke zemlje ZND, posebno za Ukrajinu. U nekim slučajevima ima smisla razgovarati o administrativnim zadacima odnosa poslodavac-korisnik-administrator. Istorijski gledano, ovi odnosi nisu bili adekvatno regulisani internim korporativnim pravilima i uputstvima.
U procesu pripreme materijala obavljeni su intervjui sa stručnjacima iz oblasti bezbednosti, računarskog prava i sistem administratorima. Velika većina je navela potrebu dokumentovanja pravila za korisnike za rad sa informacionim sistemom organizacije.
Pravilno planiranje uključuje i bavljenje finansijskim pitanjima. Potrebno je procijeniti troškove legalizacije postojećeg informacionog sistema, troškove uvođenja novog i procijeniti trošak vlasništva u dogledno vrijeme.
Svaki projekat, uključujući i projekat migracije, može se suočiti sa potcjenjivanjem ljudskog faktora. Naravno, bit će potrebna primjena metoda upravljanja ljudskim resursima. Većina sistem administratora i IT menadžera poznatih autoru nisu specijalisti u oblastima upravljanja osobljem ili finansijama. Ovako složen zadatak ne može da reši jedno IT odeljenje.
Prvi zadatak na putu migracije na novi, ciljni sistem je stvaranje radne grupe za planiranje migracije. Ova grupa je odgovorna za sprovođenje migracije i stoga bi trebalo da ima prilično široka ovlašćenja.
Cilj projekta je izgradnja ekonomski isplative IT infrastrukture. Dobar kandidat za poziciju šefa radne grupe bio bi top menadžer preduzeća ili organizacije, na primjer, finansijski direktor. Naravno, u ovu grupu spada i šef IT odjela, koji posjeduje viziju cjelokupne IT infrastrukture kako u ovom trenutku tako iu budućnosti. Kao dio grupe, potreban je iskusan sistem administrator, po mogućnosti sa iskustvom u radu sa slobodnim softverom. Veličina grupe se ne može procijeniti - u nekim slučajevima su uključeni i drugi zaposlenici firme ako je potrebno. Moguće je uključiti konsultanta treće strane sa iskustvom ili kompaniju specijalizovanu za takva rješenja. Rezultat rada ove grupe je detaljan plan migracije sa procjenom troškova migracije. Ili - objašnjenja neefikasnosti migracije na besplatna rješenja za organizaciju.
istraživanje (šta je)
Prvi korak bi trebao biti revizija – opis postojećeg (naslijeđenog) sistema.
Nije tajna da je godinama primijenjene "hitne" informatizacije bez uzimanja u obzir povrata sredstava utrošenih na softver, rezultat, po pravilu, bio ne samo ekonomski, već i tehnološki neuravnoteženi sistemi. Revizija softver preduzeće je revizija instalirane programe, utvrđivanje usklađenosti sa njihovim poslovnim zahtjevima.
Rezultat procesa revizije je:
Opis specifikacije instalirani softver;
Spisak identifikovanih rizika povezanih sa upotrebom nelicenciranog softvera;
Obračun troškova nabavke licenci za instalirani softver;
Obračun troškova uklanjanja nelicenciranog i instaliranja licenciranog softvera;
Utvrđivanje svrsishodnosti dalje upotrebe softvera;
Spisak identifikovanih rizika povezanih sa upotrebom softvera;
inventar softvera
Neka istraživanja pokazuju da većina lidera organizacija više pažnje posvećuje funkcionalnosti softvera koji koriste, a mnogo manje poštovanju prava na proizvode koje koriste.
Nažalost, većini organizacija nedostaje IT kultura. Ponekad čak ni predstavnici IT službe zapravo ne znaju šta je i gdje instalirano na računarima zaposlenih, a obični zaposlenici samostalno odlučuju i instaliraju softverske proizvode nabavljene iz sumnjivih izvora.
Inventar softvera pomaže u identifikaciji nelicenciranog softvera u organizaciji. Treba naglasiti da je ova manifestacija uvijek isplativa. Rezultat inventara može se koristiti za procjenu troškova legalizacije softvera korištenjem kako slobodnog tako i neslobodnog softvera.
Lideri organizacija su često zainteresovani za jasno finansijsko planiranje troškova korišćenja i razvoja softvera. Interes top menadžera za takve detalje je sasvim razumljiv – top menadžment kompanija je zainteresovan da softver pretvori u imovinu preduzeća, koja se obračunava, kontroliše i razvija slično drugim vrstama imovine.
Revizija softvera je postupak koji po pravilu oduzima dosta vremena, zahtijeva visoko kvalifikovano osoblje i poznavanje različitih specifičnih informacija u fazi analize informacija. Preporuka može biti da kontaktirate kompaniju specijalizovanu za ove usluge. Međutim, sasvim je moguće izvršiti reviziju od strane IT odjela.
U nekim organizacijama je nezgodno (često nemoguće) istovremeno izvršiti inventar softvera velikog obima. Razlozi mogu biti veličina organizacije ili sigurnosna politika. Neophodno je pronaći kompromis između efektivnosti inventara i faktora koji otežavaju takav proces.
Postoje dvije opcije za reviziju. Prva opcija je potpuna revizija, koja ispituje sva računarska postrojenja, lokalna mreža i periferije. Prednost ove metode je visoka tačnost, nedostatak je visoka cijena, velika potrošnja vremena i neugodnosti za korisnike. Dodatne prednosti ove metode su mogućnost da sami identifikuju softver instaliran od strane korisnika i da proučavaju zahtjeve korisnika za softverom na njihovim radnim mjestima koristeći posebno pripremljene upitnike. Druga opcija je revizija nekih tipičnih računarskih objekata, lokalne mreže i perifernih uređaja. U ovom slučaju, izbor objekata revizije diktira, po pravilu, funkcionalne odgovornosti korisnika. Ova metoda aproksimacije značajno smanjuje troškove zaliha, ali ima veliku grešku.
Male organizacije mogu ručno izvršiti reviziju i unijeti informacije o računarima i serverima, kao io softveru instaliranom na njima, u jednostavnu tabelu. U tom slučaju trebate navesti prisustvo ili odsustvo potrebnih licenci, potvrda o autentičnosti i ugovora o autorskim pravima za svaki od pronađenih softverskih proizvoda.
Za srednje i velike, možete preporučiti korištenje specijaliziranog softvera ili pozvati organizaciju treće strane specijaliziranu za takve usluge. U procesu izrade dokumenta obavljen je rad na pregledu alata za automatsku inventarizaciju softvera i hardvera (poznati su programi GASP, PC inventar, MSIA). eXponent Navigator (http://www.e-x.ru/pages/expnav.html), koji proizvodi eXponent, može postati preporuka.
Eksponent Navigator
Proizvod je namijenjen za reviziju hardvera i softvera preko mreže. Informacije o računarima uključuju informacije o komponentama (procesor, matična ploča, tvrdi diskovi, memorijski moduli, video kartice, mrežne kartice, štampači i drugi uređaji), operativni sistem, drajveri i softver.
Prema rečima kreatora programa, nakon organizovanja automatskog prikupljanja informacija o računarima, moguće je pregledati i organizovati ove informacije, pripremati štampane izveštaje i web publikacije, postavljati podatke u Microsoft Excel, XML i druge formate. Mogućnosti:
Automatska dijagnostika konfiguracije računala;
Automatsko prikupljanje informacija o računalima putem mreže;
Definicija instalirane opreme;
Identifikacija instaliranih programa;
Definicija karakteristika datoteke;
Napredno sortiranje, pretraživanje i odabir podataka;
Priprema tiskanih izvještaja;
Izvoz podataka u MS Excel;
Automatsko generiranje web publikacija.
Postoji ograničenje u besplatnoj verziji programa - računajući do 25 računara; cijena licence je 1 USD po 1 računaru.
dizajniramo (ono što želimo)
Obrađeni rezultati proučavanja postojećeg sistema osnova su za modeliranje novog, ciljnog sistema. Ovo pitanje je izuzetno važno i kompleksno. Komplikuje razmatranje ovog pitanja istorijski nedostatak poznavanja slobodnog softvera, posebno Linuxa, od strane većine IT menadžera i sistemskih administratora.
Postoji mnogo literature, uključujući i rusku, o Linuxu, koja opisuje prednost ove platforme sa tehnološke tačke gledišta. Međutim, sve ove prednosti su bitne, zajedno sa glavnim problemom - postojanjem širokog spektra aplikativnog softvera u različitim pravcima. Mit da postoji ograničena količina aplikativnog softvera za korporativnu upotrebu, uključujući kancelarijsku automatizaciju, je široko rasprostranjen već duže vrijeme i široko je rasprostranjen. Ogromnu većinu ovih mitova kreiraju i hrane kreatori i prodavci vlasničkog softvera i nemaju mnogo veze sa stvarnošću. Razotkrivanje ovog mita nije glavna svrha ove knjige. Ipak, vrijedno je napomenuti da je, na primjer, širina aplikativnog softvera apsolutni fantom, uzimajući u obzir istorijski uspostavljene standarde za razmjenu dokumenata. Tako, na primjer, de facto standardni uredski uređivač je Microsoft Office, uređivač rasterske grafike je Adobe Photosop, a Corel Draw je izuzetno uobičajen kao vektorska grafika.
Drugi problem je često pretjerana funkcionalnost vlasničkih proizvoda, koju ne diktiraju potrebe tržišta, već mišljenje marketara. A za ovu višak funkcionalnosti korisnik plaća dosta novca: trošak licence za pravo korištenja programa, sve veća složenost rada i povećani zahtjevi za hardverom.
Nedavno se situacija promijenila - postoji mnogo informacija o primjeni Linuxa. Verovatno bi najbolji materijal bio ovaj dokument :-), koji je planiran da pokrije dosta administrativnih i tehničkih pitanja.
Međutim, trenutno je dokument tek u izradi i informacije se mogu pronaći u različitim izvorima. Nemoguće je proći pored materijala Valerija V. Kačurova, Nesova Artema „Analozi Windows programa u Linuxu - tabela korespondencije.“ (http://linuxshop.ru/linuxbegin/win-lin-soft/). Ovaj izvor sadrži mnogo vrijednih informacija. Nažalost, čini se da su autori napustili ovo djelo. Ovaj dio stranice je redovno nedostupan, ali kopiju tabele možete pronaći na http://www.blif.net/modules.php?name=LinWin. Možete savjetovati resurse Open Source Applications Foundation
(http://www.osafoundation.org/), posebno http://www.osafoundation.org/desktop-linux-overview.pdf.
Rezultat je:
Izrada prototipa radnih stanica;
Obračun cijene licenci za predloženi softver;
Obuka korisnika;
Izrada okvirnog plana implementacije;
Lista rizika u implementaciji slobodnog softvera;
Podrška za besplatna rješenja;
Proračun ekonomske efikasnosti novog sistema do pet godina.
pilot projekat (test u borbi)
Zbog velikog broja faktora u naslijeđenom sistemu, velikog broja korisnika na potencijalno pogođene migracijom, preporučuje se da se migracija provede u malom obimu. Ova faza je neophodna za testiranje i prilagođavanje planova migracije i prototipa novog sistema. Upravo je pilot projekat osnova za donošenje odluke o uvođenju novog informacionog sistema zasnovanog na softveru otvorenog koda. Druga vrijednost pilot projekta je mogućnost informiranja korisnika o novom sistemu, dobijanja povratnih informacija od korisnika. Treći argument u korist pilot projekta bit će mogućnost preciznijeg eksperimentalnog određivanja cijene projekta.
Prilikom odabira ispitnog objekta potrebno je pronaći zlatnu sredinu. Prvo, odabrani objekt mora pružiti pouzdane podatke za procjenu. Drugo, sprovođenje pilot projekta ne bi trebalo da ima kritičan uticaj na poslovanje.
U ovoj fazi se također obučavaju sistem administratori i krajnji korisnici: obezbjeđen je prototip metodičkih materijala, dokumentacije i internet resursa. Preporučuje se da se korisnici koji učestvuju u pilot projektu „rastovare“ i daju priliku da dio vremena iskoriste za savladavanje novog sistema.
Eksperimentalna faza je posebno tražena:
Ako nije dokazana mogućnost migracije korisnika sa starog sistema na novi sistem;
Ako postoji skepticizam korisnika koji će moći usporiti proces migracije;
Organizaciji nedostaje korporativna kultura (koja je, nažalost, uobičajena u ZND);
Ako postoje ograničeni resursi za velike migracije;
Organizacija je velika i pilot projekat ne uključuje mnogo korisnika;
Ako su naslijeđeni vlasnički sistemi brzo evoluirali iu tehničkom smislu iu smanjenju troškova;
Ekonomski efekat migracije nije u potpunosti razjašnjen.
Da bi uspio, pilot projekat:
Ne bi trebalo da se odnosi na kritičnu oblast poslovanja;
Trebalo bi biti dovoljno važno za posao;
Ne bi trebao zahtijevati pretjerani resurs ljudi koji su već vremenski ograničeni;
Mora imati značajnu grupu podrške;
Mora biti obezbeđeno Povratne informacije sa korisnicima (Help Desk sistemi);
U sferi drugih ne bi trebalo postojati ograničen period (na primjer, važan period za poslovanje).
Ovisno o veličini organizacije, jedna ili više eksperimentalnih faza moguća je za preciznije određivanje nizova i troškova prelaska na besplatno. Važno je procijeniti njegove rezultate i utvrditi jesu li vizija i ciljevi praktični ili ih treba promijeniti ili možda čak i napustiti. Podatke iz ovih pilot projekata treba koristiti za prilagođavanje planova i izračunavanje konačnih troškova. U toku eksperimenta potrebno je razjasniti pitanja:
Opis prototipa radnih stanica;
Opis korisničkih postavki:
Prosječni troškovi za postavljanje tipova stanica;
Prijenos podataka iz naslijeđenog sistema u novi;
Obuka korisnika;
Obračun troškova implementacije softvera;
Podrška za besplatna rješenja.
planiranje (šta i kako)
1. Kreirajte plan migracije. Plan migracije treba da odgovori na pitanja:
Opis faza izgradnje sistema;
Identifikacija potreba za podrškom;
Opis završetka migracije.
U stvari, napravljen je konačni izbor kako će se migracija odvijati. Procijenjeni trošak migracije je odobren.
2. Opis faza izgradnje sistema. Trebalo bi napraviti procjenu faza izgradnje sistema koje najbolje podržavaju prioritete potreba korisnika.
Plan treba da odgovori na sljedeća pitanja:
U kojoj mjeri iu kojim fazama sistem treba instalirati i implementirati kako bi najbolje zadovoljio potrebe korisnika?
Šta je potrebno za svaku fazu migracije na novi sistem od korisnika organizacije i korisnika sistema?
Kakav će biti uticaj i rizik korišćenja sistema u svakom koraku inkrementa?
Faze implementacije sistema treba da budu jasno definisane u planu migracije; kupci, programeri i korisnici moraju biti svjesni. Procjene rizika moraju biti završene prije završetka plana izgradnje sistema. Mora se osigurati da su procjene planiranja razumne, pristup dobro osmišljen u skladu sa prioritetima organizacije, a potencijalni uticaj na kupce i korisnike prihvatljiv.
3. Određivanje potreba za podrškom. Trebalo bi obezbijediti optimalan nivo podrške kako bi se korisnicima pomoglo da koriste novi sistem. Osim toga, korisnicima je često potrebna služba za pomoć koja im pomaže da shvate opšte mogućnosti ciljnog sistema.
Pitanja koja treba riješiti uključuju:
Koja će obuka i operativna pomoć biti potrebna korisnicima?
Koji je ukupni nivo podrške za migraciju koji će korisnicima biti potreban da bi osigurali uspješnu migraciju?
Kako postići prihvaćanje ciljnog sistema od strane korisnika i izbjeći otpor korisnika prema implementaciji novog sistema?
Kako će kupci i korisnici biti obaviješteni o predstojećim promjenama u sistemskim karakteristikama i uslugama?
Da li je moguće da besplatno rješenje bude podržano od strane IT odjela organizacije ili bi outsourcing bio najbolja opcija?
Plan migracije trebao bi se fokusirati na rješavanje ovih problema planiranjem korisničke podrške u područjima:
Sistem prijavljivanja problema;
Usluge tehničke pomoći za nove sustave;
Tehnička pomoć korisnicima koji migriraju na nove sisteme;
Korisnički vodiči za tranziciju i dalje;
Obuka korisnika za učenje i prilagođavanje novom sistemu, za obavljanje istih vrsta zadataka;
Sposobnost testiranja upotrebe novih sistema;
Demonstracije upotrebe novih sistema da se postojećim korisnicima naslijeđenih sistema pokaže kako novi sistem funkcionira i kako mogu obavljati uporedive zadatke;
Prevazilaženje tekućih operativnih problema.
Tokom faze edukacije korisnika, obratite posebnu pažnju na one koji su posvećeni starom sistemu i/ili protivnici novih sistema.
4. Opis završetka migracije. Nakon završetka svake nove faze implementacije i obuke, programeri i implementatori moraju osigurati da korisnici migriraju na novi ciljni sistem što je udobnije moguće. Plan migracije treba da predvidi ubrzavanje migracijskih napora i uklanjanje naslijeđenog sistema što je prije moguće.
Neophodno je predvidjeti dodatni napor koji može biti neophodan za "najnovije usvojitelje" i druge korisnike koji imaju nepredviđene probleme. Drugi aspekt ove aktivnosti je procjena vremena i troškova za završetak tranzicije svih korisnika na novi sistem i uklanjanje starih sistema izgrađenih na nelicenciranom vlasničkom softveru.
Organizacioni lideri, programeri i implementatori trebali bi razmotriti uključivanje nekoliko pristupa kako bi pomogli migrirati korisnike naslijeđenih sistema:
Informisati svaku korisničku grupu kako i kada treba da migriraju svoje zadatke na nove sisteme, kako se radno opterećenje menja tokom perioda migracije sa naslijeđenih sistema;
Uspostaviti podsticaje za potpuno prelazak na novi besplatni sistem i eliminisati zavisnosti od naslijeđenih sistema;
Pružiti pomoć (softver i dodatno osoblje) za pretvaranje naslijeđenih podataka u novi sistem; - procedure za razgradnju naslijeđenih sistema;
Arhiviranje podataka naslijeđenih sistema i njihovo skladištenje.
migracija (učiniti)
Sve što ostaje u posljednjoj fazi je raditi po planu.
Aktivno upravljajte i kontrolirajte procese migracije:
Postaviti kriterije mjerenja i pratiti korake migracije i troškove resursa za migraciju;
Vršiti periodične preglede situacije i upoznati sa njima, u skladu sa mandatom i organizacionom politikom, dotične ljude (menadžment, menadžeri projekta i sponzor);
Uspostaviti sistem praćenja za upravljanje napretkom procesa (napretkom), pitanjima, rezolucijama i drugim poslovnim pitanjima vezanim za planiranje migracije i planove implementacije.
Vadim Maškov, UA-FOSS, [email protected]
Sergey Berdachuk, 1.0 2006.12.01
Čini se da bi prisustvo već postojećeg informacionog sistema (IS) trebalo da pojednostavi i ubrza razvoj novog IS baziranog na starom, ali u praksi se najčešće dešava upravo suprotno. Prvo, budući da je postojala potreba za kreiranjem novog IS-a, to najčešće znači da je prethodno kreirani IS kreiran sa značajnim nedostacima i prepun raznih grešaka.
Obično sa IP adrese koju su godinama pisali razni programeri. Istovremeno, projektna dokumentacija je najčešće u jadnom stanju, a ponekad i potpuno odsutna. "Pravi" programeri ne pišu dokumentaciju, a još manje kod dokumenta. Zašto, jer je sve jednostavno i transparentno. Ipak, kada pogledate sopstveni kod nakon pola godine, prilično je teško shvatiti šta je tu urađeno. Pogotovo ako je za to vrijeme urađeno još nekoliko projekata.
Štaviše, svaki novi programer se obično ne trudi da pažljivo prouči ni kod ni arhitekturu sistema. Budući da rokovi uvijek “gore”, “spravice” su jednostavno napisane za privremeno rješenje hitnog problema. Rezultat je "kaša" koja se sastoji od mnogo različitih modula i nekako čudesno spojenih tehnologija koje ponekad nisu kompatibilne jedna s drugom. Situacija je pogoršana upotrebom naslijeđenih sistema za upravljanje bazama podataka (DBMS) za skladištenje podataka, kao što su dbase-III, FoxPro ili Clipper. Odsustvo koncepta transakcije, kao i nesposoban dizajn i referentni integritet, dovodi do brojnih povreda integriteta podataka. Može se smatrati srećnim ako je stari sistem koristio DBMS, ponekad postoje kreacije koje koriste tekstualne fajlove za skladištenje podataka (prilikom migracije jednog od ovih sistema, autor je morao da napiše poseban drajver za pristup takvoj bazi podataka).
Možda je jedina pozitivna točka nagomilano iskustvo u formiranju zahtjeva za novorazvijenim IS. S druge strane, iskustvo komunikacije sa starim sistemom može postati značajna kočnica za uvođenje novog proizvoda. Najčešće se to događa zbog razlika u konstrukciji vizualnog sučelja i funkcijskih tipki koje se koriste za izvođenje određenih operacija. Dakle, neke od funkcijskih tipki operativni sistem može rezervirati za obavljanje određenih radnji. Tipičan primjer je upotreba tipke "Enter" za prelazak na sljedeći element obrasca koji se može uređivati u starijim DOS IC-ovima. U grafičkim interfejsima, tipka "Tab" se obično koristi za ovu svrhu. Kao rezultat toga, dobijamo snažno protivljenje korisnika prilikom implementacije nova verzija proizvod. Naravno, moguće je emulirati ponašanje korisničkog interfejsa (User Interface) sučelja starog sistema, ali je najbolje to učiniti opciono. One. uvesti mogućnost konfigurisanja ponašanja sistema u IS konfiguracionom modulu, i podrazumevano koristiti postavke koje odgovaraju trenutnom operativnom sistemu. U suprotnom će novorazvijeni proizvod biti teško naučiti novim korisnicima koji očekuju da se program ponaša u skladu sa trenutnim standardima.
Što se tiče rada sa pohranjenim podacima starog sistema, situacija je još gora. Odluka menadžmenta da koristi neke od modula starog sistema imaće najteže posledice. Na primjer, kada se suočimo sa zadatkom izrade nove verzije skladišnog računovodstva, a rješavanje ostalih zadataka (računovodstvo i sl.) za sada će se baviti starom verzijom IS-a. U ovom načinu rada javlja se problem migracije podataka u režimu "realnog" vremena. Režijski troškovi održavanja rada svih modula u cjelini mogu premašiti troškove razvoja nove verzije svih modula. Štaviše, troškovi se mogu razlikovati po redosledu veličine, uzimajući u obzir moguće gubitke zbog nedostataka starog sistema i grešaka u razmeni i konverziji podataka. Dakle, treba pažljivo procijeniti stanje starog IS-a i njegovu izvodljivost. I što je najzanimljivije, u praksi se na ovaj problem obično ne utiče, sve do pojave: „Ovde ćemo napraviti novi sistem, a onda ćemo se baviti spajanjem sa drugim softverom i migracijom podataka“.
Ali onda dolazi trenutak kada je problem zreo, novi sistem je napisan i vrijeme je za konvertiranje i prijenos podataka u novi sistem. Analizirajući iskustvo migracije podataka velikog broja različitih informacionih sistema, može se izdvojiti tipična procedura migracije podataka koja uključuje:
Najjednostavnija opcija je obično kreiranje srednjeg programa. Mora komunicirati s izvornom i odredišnom bazom podataka i izvršiti potrebne transformacije.
Rice. 1. Opcija sa međuverskim softverom za migraciju podataka
Značajan nedostatak ovog rješenja može biti opterećenje mreže tokom prijenosa podataka. Ako je količina podataka značajna, onda mrežna komunikacija može uvelike utjecati na performanse.
Bolje rješenje bi moglo biti prethodno učitavanje starih podataka u privremene tablice novog DBMS-a. Moderni DBMS (na primjer, Oracle) obično sadrže posebne uslužne programe koji omogućavaju vrlo brzo preuzimanje vanjskih podataka u različitim formatima. Sam modul za migraciju je napisan na proceduralnim jezicima ugrađenim u DBMS (na primjer, PL/SQL ili java). Možete značajno povećati brzinu postupka migracije zbog činjenice da ugrađeni programski jezici rade u svom „nativnom“ okruženju, optimizirani su za ciljni DBMS i nema dodatnih troškova za razmjenu podataka preko mreže .
Rice. 2. Opcija migracije podataka pomoću DBMS-a
Iz praktičnog iskustva pisanja ovakvih programa, želio bih skrenuti pažnju na korištenje batch SQL metoda koje podržava većina DBMS-a i programskih jezika (na primjer, metode addBatch() i executeBatch() u java-i). Izvršavanje jedne INSERT ili UPDATE izraza za niz podataka u serijama od 100 - 200 zapisa daje značajan dobitak u performansama, u poređenju sa izvršavanjem ove naredbe u petlji za svaki zapis zauzvrat.
Moderne kompanije se često suočavaju s potrebom da migriraju svoje informacioni sistemi. Međutim, implementaciji ove procedure treba prethoditi pažljiva priprema, jer na tom putu ima mnogo prepreka.
Razloga za početak tranzicije na novi informacioni sistem (IS) može biti mnogo, uključujući smanjenje rizika povezanih sa radom zastarelih platformi, dovođenje informacionih sistema na međunarodne standarde i povećanje efikasnosti poslovnih procesa. Ali bez obzira koji je zadatak pred kompanijom, prelazak iz jednog IS-a u drugi mora biti pažljivo isplaniran i pripremljen.
Kada je u pitanju migracija transakcionih sistema, kao što su ERP, fakturisanje, obrada ili ABS, prelazak na novi sistem je veoma problematičan. Poenta je da IT profesionalci treba da obezbede tačnu migraciju velikih količina podataka, održavajući paralelni rad starog i novog sistema za usaglašavanje i analizu rezultata.
Na primjer, imao sam projektno iskustvo u jednoj od najvećih banaka, gdje je došlo do tranzicije transakcionog sistema sa više nepodržane Informix platforme na Oracle platformu. Istovremeno, bilo je potrebno izvršiti detaljnu analizu poslovnih procesa, više puta prenositi podatke iz starog sistema u novi, te provjeriti usklađenost rezultata rada novih i starih sistema, uzimajući u obzir trajanje procesnih propisa. Zato je period migracije bio 14 mjeseci. Ponekad se paralelni rad dva sistema može nastaviti i duže, ali čak i kada je ograničen na nekoliko mjeseci, da bi se osigurao rad novog IS-a, potrebno je izdvojiti dodatnu računarsku snagu i značajno vrijeme za zaposlene u preduzeću. da istovremeno obavljaju zadatke u dva sistema.
IP se često ažurira kao dio globalizacije i centralizacije. Ovo vam omogućava da značajno smanjite troškove održavanja i ažuriranja softverskih sistema. Zaista, održavanje jedinstvene platforme koja služi svim zaposlenima je mnogo lakše nego održavanje zasebnih alata za svaki odjel. Na primjer, uspješna migracija sistema kontrole zaliha može dovesti nekoliko hiljada odjela velike organizacije na jednu platformu i obezbijediti značajno smanjenje IT troškova. Međutim, treba imati na umu da većina priprema u ovom slučaju pada na koordinaciju podataka u različitim formatima i reprezentacijama, izradu novih propisa i izgradnju novih modela interakcije zaposlenih.
Drugi važan aspekt- integracijska sučelja sa drugim IS-ima preduzeća, posebno samopisnim i specifičnim. Problemi koji su s njima povezani možda nisu toliko uočljivi u prvoj fazi, ali se identifikuju prilikom uspostavljanja interakcije različitih odjela sa cjelokupnim sistemom. A ako su za stari sistem takvi interfejsi već implementirani programski ili organizaciono, onda će za novi sistem možda morati da se razvijaju iznova.
Treba imati na umu da razmišljanja o proširenju funkcionalnosti sistema mogu doći već tokom implementacije projekta, baš kao što apetit dolazi s jelom. A to znači da će biti potrebno mnogo dodatnog rada.
Iskustvo projektnih aktivnosti migracije sistema pokazuje da svaki takav projekat zahtijeva pažljivu pripremu i mora biti popraćen individualnim planom. Međutim, bez obzira na vrstu sistema koji se migriraju, softver, veličinu baze podataka, itd., opća šema izgleda gotovo identično.
U prvoj fazi potrebno je izvršiti detaljnu reviziju, utvrditi sve zahtjeve za način rada novog sistema, intervjuisati sve ključne korisnike. Važno je razumjeti o kojim količinama podataka, kakvom opterećenju je riječ, tek tada će stručnjaci moći ponuditi pravu strategiju migracije.
Same procedure takođe treba da budu pažljivo osmišljene i uključuju tako važne elemente kao što su pravila za pristup korisnika sistemima tokom migracije, procedure vraćanja nazad u slučaju kvarova i interakciju različitih stručnjaka uključenih u ove procese.
Nakon dogovora sa kupcem obično se izrađuje detaljan plan koji uključuje nekoliko faza, a to su: kopiranje podataka, njihova verifikacija, paralelni rad dva sistema i potpuni prelazak na novu platformu. Po mom mišljenju, glavna stvar u profesionalno organizovanoj migraciji sistema je nesmetanost ovog procesa za korisnike koji mogu postepeno, bez stresa, početi da rade u novom automatizovanom sistemu.
Međutim, čak i temeljita priprema vas ne spašava uvijek od potcjenjivanja troškova rada prilikom prebacivanja korisnika na „nove šine“. Ovaj proces uključuje kako obuku zaposlenih u kompaniji, tako i njihovu podršku u periodu adaptacije na novi sistem.
U ovom članku želimo sistematizirati naše iskustvo u provođenju migracije podataka u velikim korporativnim projektima koji se odnose na prelazak kupaca na rad u 1C:Enterprise 8 konfiguracijama.
Istovremeno, glavni naglasak u članku će biti stavljen, prije svega, na tehnološku komponentu procesa migracije. Organizaciona komponenta je takođe pogođena, ali u manjoj meri.
Migracija podataka se obično shvata kao konačna sekvenca rada, projekat koji ima za cilj jednokratno masovno premještanje podataka iz izvornih sistema (istorijskih sistema) u sistem prijemnika. Istovremeno, rad ovih podataka u izvornim sistemima je prekinut.
Migraciju podataka treba razlikovati od integracije podataka. Integracija je, za razliku od migracije, stalni dio IT arhitekture i odgovorna je za protok podataka između različitih sistema i skladišta podataka – i predstavlja proces, a ne projektnu aktivnost.
Shema migracije općenito izgleda ovako:
Rice. jedan
Istorijski sistemi- baze podataka kompanije Kupca, koje se planiraju u potpunosti ili djelimično zamijeniti tokom implementacije novog sistema.
Sistem prijemnika- ciljni sistem, proizvoljna konfiguracija "1C:Enterprise 8".
Početni podaci- podaci preuzeti iz istorijskih sistema u proizvoljan xls-format. U ovom slučaju, xls format se čini jednim od najpogodnijih, budući da je mogućnost učitavanja u xls datoteku prisutna u mnogim računovodstvenim sistemima "prethodne generacije".
Kao modernu alternativu, moguće je smatrati format xml datoteka kao transport.
Postoje i opcije za korištenje srednje baze podataka.
Transformacija, konverzija- proces pretvaranja neobrađenih podataka u podatke za preuzimanje. Transformacija podataka se dešava u skladu sa šablonima za učitavanje. Rezultat transformacije su podaci koji se učitavaju.
Podaci za preuzimanje- podatke koji se učitavaju u prijemni sistem. U ovom članku, kao i izvorni podaci, razmatra se xls format.
Preuzmite predloške podataka- opis tablica podataka koje treba učitati u ciljni sistem.
Razmotrite proces pripreme i provođenja migracije korak po korak.
Organizacione faze migracije uključuju sljedeće stavke:
· Definisati strategiju migracije. U ovoj fazi, Izvođač i Naručilac se dogovaraju o tehnologiji migracijskog rada;
· Određivanje sastava radne grupe za migracije. Radna grupa treba da uključuje stručnjake i iz izvođača i iz naručioca, koji su dovoljno upoznati sa radom istorijskih sistema (od strane naručioca) i ciljnog sistema (od strane izvođača);
· Preliminarni plan migracije. Plan migracije će se više puta prilagođavati tokom projekta;
· Datumski periodi za istovar podataka iz istorijskih sistema, količine podataka. Periodi prekida podataka za migracije, datumi testiranja i konačne migracije. Ove informacije može se pripisati planu migracije;
· Sastav podataka za migraciju. Referentni podaci, klasifikatori, transakcijski podaci, stanja, promet, itd.;
· Pitanja provjere kvaliteta, ispravnosti i integriteta podataka tokom i nakon migracije;
· Problemi vraćanja na prethodno stanje u slučaju kvarova.
Zaustavimo se detaljnije na tehnološkim fazama migracije.
Rice. 2
Predložak za učitavanje podataka sadrži tehničke opise tablica podataka koje treba učitati, algoritme i pravila učitavanja za trenutni predložak.
Svaki predložak je općenito namijenjen jednoj ili više povezanih tablica na odredišnom ciljnom sistemu.
Šablon navodi:
Opis svih polja xls datoteke podataka koja će se učitati, uključujući:
o Ime polja
o Znak obaveznog polja
o Primjer popunjavanja polja
o Napomena
Opis pravila za učitavanje tabele ciljnog sistema na osnovu podataka koji se učitavaju (redosled u slučaju više povezanih tabela, algoritmi pretraživanja ključnih polja, itd.)
· Opis popunjavanja polja tabela ciljnog sistema direktno u slučaju da je predviđeno nešto drugo osim jedan-na-jedan prenos podataka iz datoteke podataka za učitavanje. Relevantno za referentna polja, na primjer.
U toku rada na ovoj fazi, Izvođač mora pripremiti i učitavač podataka za učitavanje. U slučaju rada sa xls datotekama, ovaj zadatak nije posebno težak.
Ovaj korak može započeti zajedno s prethodnim korakom „1. Priprema šablona za učitavanje podataka”.
Kao dio ove faze, stručnjaci Kupca određuju iz kojih sistema i koji podaci se mogu učitati. Također je potrebno utvrditi koji podaci Možda može biti potrebno.
U pravilu, u velikim migracijskim projektima, identifikacija potpune iscrpne liste izvora podataka može potrajati dosta vremena i dešava se kako se posao obavlja u narednim fazama.
Nisu neuobičajene situacije kada se, da bi se osigurao integritet informacija u budućnosti, neki podaci moraju prenijeti iz štampanih izvora (digitalizirati) ili čak unijeti u tabele sa riječi ključnih djelatnika Kupca.
Međutim, u ovoj fazi trebate pokušati identificirati što je moguće više potrebnih podataka.
Proces izbacivanja podataka iz istorijskih sistema može potrajati dovoljno vremena, posebno ako postoji mnogo sistema, različiti su i za njih su odgovorna različita odeljenja Korisnika. Potrebno je uzeti u obzir ovaj momenat tokom testnih i finalnih migracija.
Čini se da je najpogodnija opcija otpremanje u xls datoteke. Mnogi stariji IT sistemi podržavaju ovu opciju.
Mogu postojati i opcije za otpremanje u csv format, dbf, xml formate i druge.
Treba napomenuti da iz ovog ili onog razloga (sigurnosni problemi, na primjer) Kupac ne može uvijek u ovoj fazi omogućiti učitavanje podataka u potpunosti! Samo struktura podataka i nekoliko testnih pozicija. Stoga može doći do situacije da će se tijekom probnih i završnih opterećenja u izvornim tablicama naći podaci loše kvalitete, što će dovesti do neplaniranih grešaka.
Da bi se ovaj problem sveo na najmanju moguću meru, količine testnih preuzimanja sa istorijskih sistema treba da budu specificirane unapred.
Mapiranje (mapiranje podataka) - u opštem slučaju, proces poređenja podataka iz istorijskih sistema i sistema koji prima. To jest, izvorni podaci i podaci koji se učitavaju.
Faza mapiranja je faza koja oduzima najviše vremena i može uzeti više od 50% cjelokupnog posla na zadatku migracije.
U ovoj fazi je u potpunosti uključena cijela radna grupa projekta o migracijama.
U procesu mapiranja podataka potrebno je razlikovati podfaze mapiranja tablica i mapiranja polja.
· Mapiranje tabela, odnosno mapiranje šablona - poređenje tabela početnih podataka i šablona podataka za učitavanje. Korespondencija može biti 1:1 ili N :N. Kao rezultat ovog rada, sastavlja se i održava registar mapiranja tablica. Ovaj podkorak je potreban za sljedeći podkorak mapiranja polja i za praćenje ukupnog napretka mapiranja.
|
Grupa šablona 1C |
Naziv šablona 1C |
Ime dokumenta- izvor |
Pravila za generiranje izvorne datoteke |
Odgovorno |
Status |
Bilješka |
|
NSI |
uzorak_ Nomenklatura |
Nomenk latura.xls |
U sistemu N postavite izbor |
Ivanov I.I. |
na poslu |
· Mapiranje polja - poređenje polja tabela u okviru već definisanog mapiranja tabela. Rezultat ovog rada je registar mapiranja polja.
|
br. str |
Cl. polje |
Obavezno |
Naziv polja predloška 1C "Template_Nomenclature" |
Opis |
Naziv polja "Nomenclature.xls" |
Algoritam popunjavanja |
||||||||
|
Šifra |
Šifra elementa imenika |
Šifra |
||||||||||||
|
Ime |
Ime |
|||||||||||||
|
Da |
Ova grupa |
Sadrži jednu od sljedećih vrijednosti: |
Ako je dužina koda 11 znakova i zadnja 4 znaka<>"0000", onda je ovaj element "0", inače je grupa "1". |
|||||||||||
|
Puno ime |
Ime elementa direktorija |
Ime |
Ako je OvaGrupa =1, Onda "", ElseIf OvaGrupa=0, onda Ime. |
|||||||||||
U okviru ove faze trebalo bi da se sprovede i mogući rad na normalizaciji podataka.
Za razliku od prethodnih faza, ova faza je tehnička i uključuje rad programera Izvođača.
Na osnovu dogovorenih registara mapiranja terena, stručnjaci Izvođača razvijaju pravila transformacije podataka.
Za operativni rad tokom pripremnih faza migracije i dalje, tokom testnih i finalnih migracija, važno je da postoji pogodno okruženje za razvoj pravila transformacije podataka (skripte) i okruženje za pretvaranje početnih podataka u podatke za učitavanje.
Zahtjevi za ovo okruženje uključuju:
· Pogodnost i brzina razvoja pravila transformacije;
· Brzina konverzije podataka. Ulazne i izlazne datoteke mogu biti dugačke stotine hiljada redova!
· Mogućnost rada sa više ulaznih datoteka istovremeno;
· Mogućnost čuvanja pravila transformacije u odvojenim datotekama.
Za naše projekte migracije razvili smo specijalizovanu radnu stanicu za programere, zasnovanu na standardnoj obradi „Request Console“ 1C.
Rukovanje "Konzolom upita" je poboljšano kako bi se omogućili direktni zahtjevi za xls datoteke.
Evo primjera kombiniranja dvije izvorne xls datoteke Zaposleni.xls
|
Šifra zaposlenika |
Prezime |
Ime |
srednje ime |
Datum rođenja |
|
2423 |
Ivanov |
Ivane |
Ivanovich |
17.11.1992 |
|
1523 |
Petrov |
Bosiljak |
Aleksandroviču |
04.02.1991 |
|
4363 |
Sidorov |
Kirill |
Nikolaevich |
01.05.1995 |
|
Denisov |
Denis |
Denisovich |
01.01.1990 |
i Operacije.xls sa stranicama:
Otpisi
|
Šifra zaposlenika |
datum |
Suma |
|
2423 |
01.02.2014 |
|
|
1523 |
02.02.2014 |
|
|
4363 |
03.02.2014 |
|
|
04.02.2014 |
100000 |
|
|
2423 |
05.02.2014 |
|
|
1523 |
06.02.2014 |
|
|
4363 |
07.02.2014 |
2356 |
|
08.02.2014 |
140000 |
|
|
2423 |
09.02.2014 |
|
|
1523 |
10.02.2014 |
|
|
4363 |
11.02.2014 |
23523 |
|
12.02.2014 |
80000 |
i Prihodi:
|
Šifra zaposlenika |
datum |
Suma |
||
|
01.05.2004 |
||||
|
02.05.2004 |
||||
|
03.05.2004 |
||||
|
04.05.2004 |
||||
|
2423Datum rođenja |
Primljeni iznos |
Iznos otpisa |
||
|
Ivanov Ivan Ivanovič |
2423 |
17.11.1992 |
1341234 |
1010 |
|
Petrov Vasilij Aleksandrovič |
1523 |
04.02.1991 |
245245 |
|
|
Denisov Denis Denisovich |
01.01.1990 |
380000 |
320000 |
|
|
Sidorov Kiril Nikolajevič |
4363 |
01.05.1995 |
613382 |
26336 |
|
UKUPNO: |
2579861 |
347842 |
Imajte na umu da je primjer umjetni, posebno odabran da demonstrira sve moguće faze transformacije izvora podataka.
Tehnološki slijed operacija transformacije je sljedeći:
Koristeći Access SQL jezik upita (koji pruža značajne dodatne karakteristike u poređenju sa 1C jezikom upita), kreira se početni upit koji preuzima podatke iz xls datoteke u 1C okruženje. Istovremeno, već su u ovoj fazi moguće razne provjere i normalizacije podataka.
ADO tehnologija pristupa podacima pruža velika brzina rad.
Rice. 3
2. Zahtjev na 1C jeziku - glavni zahtjev koji implementira algoritam mapiranja polja. I također: obogaćivanje preuzetih podataka podacima iz 1C baze podataka, pregrupisavanje, spajanje s rezultatima upita drugim izvornim xls datotekama itd.
3. Po potrebi naknadna obrada rezultata 1C zahtjeva. Implementira se pomoću skripte na 1C jeziku.
Na primjer, ovdje je implementirano dodavanje reda "UKUPNO" za kolone iznosa.
4. Snimanje konačnog skupa podataka u xls-datoteku.
U opštem slučaju, na izlazu dobijamo konačne datoteke za učitavanje u ciljnu 1C bazu podataka.
Također, ovaj alat vam omogućava da spremite pravila konverzije podataka u zasebnu xml datoteku:
Osim toga, moguće je raditi in batch mod, što je posebno važno s velikom količinom heterogenih podataka o migraciji.
U toku prethodnih faza završava se pripremni dio rada u cjelini - identifikuju se svi izvori podataka, istovaruju se početni podaci iz izvora, pripremaju šabloni za učitavanje u ciljnu bazu podataka, priprema mapiranje podataka i, konačno, razvijaju se skripte za transformaciju podataka.
Treba napomenuti da prije konačne migracije svakako trebate provesti nekoliko testnih. Tokom probnih migracija, Izvođač zajedno sa Kupcima identifikuje:
greške konverzije, greške učitavanja podataka
izvršiti preliminarnu procjenu kvaliteta podataka učitanih u ciljni sistem
Na osnovu rezultata testnih migracija sastavljaju/ažuriraju konačni plan migracije
Provjeru kvaliteta preuzetih podataka treba izvršiti i nakon testnih migracija i na kraju završne migracije. Tokom usaglašavanja mogu se provjeriti sljedeći indikatori:
· Poklapanje ukupnih iznosa za bilanse, za dokumente;
Kvantitativna podudaranja, kao što je broj OS;
· Ispravnost popunjavanja posebnih selektivnih entiteta;
Imajte na umu da se određene provjere migracijskih podataka, pitanja normalizacije podataka moraju rješavati kroz sve procese migracije. Uvijek se morate zapitati šta treba učiniti u trenutnoj fazi kako biste izbjegli greške u narednim fazama.
Na primjer:
· Provjerite ima li duplikata po ključnim poljima. Moguće je i potrebno izvršiti još na početnim podacima;
· Vrste polja za livenje;
· Referentni integritet;
· Matematičke nedoslednosti. Na primjer, provjera praznih numeričkih polja, koja se planiraju podijeliti tokom transformacije;
· Općenito, provjera obaveznog popunjavanja polja;
· Zamena netačnih znakova. Na primjer, engleski znakovi u poljima ćirilice ("o", "a", "e" itd.) Ovo posebno vrijedi za ključna polja!
Provjera vrijednosti polja stringova za usklađenost s tipovima prijemnog sistema (ograničenja dužine)
Nakon što je finalna migracija završena, prema unaprijed utvrđenoj strategiji migracije i planu migracije, donosi se odluka o daljem radu naslijeđenih sistema.
Često se rad završi odmah nakon konačnog usaglašavanja podataka i uspjeha migracije – korisnici novog sistema više ne vode evidenciju paralelno u dva sistema, već u potpunosti prelaze na novi sistem. Istovremeno, pristup starom sistemu je sačuvan u načinu čitanja.
U nekim slučajevima može doći do paralelnog rada dva sistema tokom perioda probnog rada (OE) pa čak i duže od ovog perioda. Pitanje paralelnog rada korisnika u dva sistema usko je povezano sa pitanjem mogućnosti vraćanja na stari sistem, ukoliko se utvrdi da je migracija (ili, generalno, rad novog sistema!) nezadovoljavajuća.
U zaključku, želio bih napomenuti da kada je u pitanju migracija velikih transakcionih sistema, koji uključuju mnoge 1C:Enterprise konfiguracije, prelazak na novi sistem može biti dugotrajan.
Stoga treba imati na umu da svaki takav projekt zahtijeva pažljivu pripremu i mora biti popraćen individualnim planom. Međutim, bez obzira na vrstu sistema koji se migriraju, obim baza podataka, itd., opšta šema migracije izgleda gotovo identično.
