Moderne kompanije se često suočavaju sa potrebom da migriraju svoje informacione sisteme. Međutim, ovom postupku mora 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 sa kojim se zadatkom kompanija suočava, prelazak sa jednog IP-a na drugi mora biti pažljivo isplaniran i pripremljen.

Problemi migracije

Kada je u pitanju migracija transakcionih sistema kao što su ERP, fakturisanje, obrada ili osnovno bankarstvo, prelazak na novi sistem je veoma problematičan. Činjenica je da IT profesionalci moraju osigurati tačnu migraciju velikih količina podataka, održavajući paralelni rad starog i novog sistema za usklađivanje i analizu rezultata.

Na primjer, imao sam projektno iskustvo u jednoj od najvećih banaka, gdje se transakcioni sistem prenosio 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 konzistentnost rezultata novih i starih sistema, uzimajući u obzir trajanje procesne regulative. Zbog toga je period migracije bio 14 mjeseci. Ponekad se paralelni rad dva sistema može nastaviti duže vrijeme, ali čak i kada je ograničen na nekoliko mjeseci, osiguranje rada novog IS-a zahtijeva dodjela dodatne računarske snage i značajnog vremena zaposlenih u preduzeću za istovremeno obavljanje zadataka u dva sistema. .

Od sistema odjela do nivoa poduzeća

Ažuriranje IP-a se često dešava u okviru globalizacije i centralizacije. Ovo vam omogućava da značajno smanjite troškove podrške 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 računovodstva zaliha omogućava vam da prebacite nekoliko hiljada odjela velike organizacije na jednu platformu i osigurate ozbiljno 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.

Još jedan važan aspekt su integracijska sučelja sa drugim informacionim sistemima preduzeća, posebno onima koji se sami pišu i specifičnim. Problemi koji su s njima povezani možda nisu toliko uočljivi u prvoj fazi, ali se identifikuju prilikom uspostavljanja interakcije između različitih odjela i cjelokupnog sistema. A ako su za stari sistem takvi interfejsi već bili 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 se apetit javlja tokom obroka. To znači da će biti potreban čitav niz dodatnih radova.

Akcioni plan

Iskustvo projektnih aktivnosti na migraciji sistema pokazuje da svaki takav projekat zahtijeva pažljivu pripremu i mora biti popraćen individualnim planom. Međutim, bez obzira na tip sistema koji se migrira, softver, volumen baze podataka, itd., opšta š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 i o kakvom opterećenju je riječ, tek tada će stručnjaci moći predložiti pravu strategiju migracije.

Same procedure također moraju biti pažljivo osmišljene i uključuju takve važne elemente kao što su pravila za pristup korisnika sistemima tokom migracije, procedure za vraćanje na prethodno stanje 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, verifikacija, paralelni rad dva sistema i potpuni prelazak na novu platformu. Po mom mišljenju, glavna stvar u profesionalno organizovanoj migraciji sistema je glatkoća procesa za korisnike koji mogu postepeno, bez stresa, početi da rade u novom automatizovanom sistemu.

Međutim, čak i pažljiva 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.

Leif Poulsen za InTech

Sistemi za automatizaciju proizvodnje i prikupljanje informacija o proizvodnim procesima su relativno kratkog veka. Često ih je potrebno nadograditi ili zamijeniti prije nego procesna oprema dostigne kraj svog vijeka trajanja. Za mnoge kompanije, upravljanje zamjenom ili nadogradnjom ovakvih sistema automatizacije bez zaustavljanja proizvodnje je pravi izazov. Stoga se objektivna potreba za modernizacijom ili zamjenom ignorira dok se nešto ne dogodi. Ovaj članak govori o tome kako možete uspješno izvršiti ovaj zadatak kroz pažljivo planiranje i organizaciju.

Dva glavna faktora stoje iza potrebe za modernizacijom i zamjenom sistema industrijske automatizacije i industrijskih IT sistema: tehnička degradacija ovih sistema, kao i promjene u zahtjevima poslovnih procesa koje ovi sistemi podržavaju.

Pouzdanost tehničkih sistema će se vremenom smanjiti ako kompanije ignorišu potrebu za modernizacijom operativnih sistema, baza podataka i aplikativnog softvera. Shodno tome se povećava operativni rizik od kvara opreme.

Pažljivim planiranjem, operativni rizik se može održati na prihvatljivom nivou, uz istovremeno zaštitu investicija i minimiziranje troškova životnog ciklusa. Za tipičan sistem automatizacije ili IT sistema, samo 20-40% ulaganja ide u kupovinu sistema. Preostalih 60-80% ide na održavanje visoke dostupnosti i prilagođavanje periodično promjenjivim zahtjevima.

Uz procjenu aktivnosti potrebnih za sprječavanje tehničke degradacije, potrebno je razmotriti nove izazove, kao i potencijalne poslovne prilike. Poslovno okruženje se stalno mijenja i uvijek se moraju uzeti u obzir sve mogućnosti za poboljšanje postojećih ili uvođenje novih tehnologija. Tipične poslovne prilike koje mogu pokrenuti migraciju skupih sistema automatizacije su brzina na tržište, konkurentnost, rast, kvalitet i usklađenost sa propisima.

Dugoročni plan migracije

Izrada dugoročnog plana migracije sistema omogućava kompanijama da održavaju sistemske operativne rizike na prihvatljivom nivou. Osim toga, osigurava upravljanje rizicima i pravovremenu podršku poslovnim ciljevima. Plan migracije mora uzeti u obzir ograničenja kao što su „najbolje proizvodne prakse“, tehnološka funkcionalnost i neizbježni prekidi proizvodnje.

Općenito, pristup dugoročnom planiranju prikazan je na slici 1. Plan migracije se razvija kako bi se utvrdilo gdje kompanija želi biti za pet godina, koje radnje treba poduzeti da bi se tamo stiglo i da li su resursi potrebni da se tamo stigne. Ovaj pristup se zasniva na principima arhitektonskog projektovanja navedenim u standardu TOGAF, koji se široko koristi u razvoju sistemske arhitekture za industrijska preduzeća.

Slika 1. Opšti pristup kreiranju dugoročnog plana migracije.

Potrebno je razlikovati postojeću arhitekturu od ciljne, željene. Razlika između njih odražava razliku između trenutne pozicije kompanije i pozicije koju želi da zauzme u budućnosti. Plan migracije prikazuje put od postojeće arhitekture do ciljne arhitekture - moguće kroz nekoliko prelaznih faza.

Svaka arhitektura se može opisati kao niz "slojeva" koji premošćuju jaz između poslovanja i tehnologije - kao što je prikazano na slici 1. 1. Pažnja se mora obratiti na sljedeće „slojeve“:

• Poslovni ciljevi to je dio ukupnog napora planiranja strategije. Oni vam omogućavaju da odaberete pravi smjer procesa.
• Poslovni model pruža kontekst u kojem se razumiju proizvodni i poslovni procesi. Obično uključuje opis na visokom nivou materijalnih tokova i procesa.
• Opis proizvodnih i poslovnih procesa važan je za uspješnu primjenu tehnologija i ispravnu procjenu njihove vrijednosti sa poslovnog stanovišta.
• Informacije, podaci i dokumenti važno za povezivanje procesa i aplikacija. Interoperabilnost i upravljanje tokovima informacija između aplikacija su posebno važni.
• Opisi aplikacije omogućavaju vam da formulišete zahteve visokog nivoa i definišete interfejse.
• Definicija infrastrukturu, računarstvo i mrežu zahtjevi (hardver, tolerancija grešaka, performanse).
• Pod uslovom usluge definisati zahtjeve za osiguranje efektivnog operativnog upravljanja i podrške odlučivanju.

Izrada plana migracije

Razvijanje plana migracije za cijelu organizaciju, ili čak jednu proizvodnu lokaciju, može biti zaista složen zadatak koji uključuje mnogo ljudi. Preporučuje se da se proces razvoja podijeli u nekoliko faza, opisanih u nastavku.

Dio II

Faza 1: Mobilizacija

Osnovni ciljevi:

• postići zajedničko razumijevanje zadataka i ciljeva
• mobilizirati organizaciju u kojoj je projekat planiran
• detaljnije izložite plan opisivanjem prekretnica i rezultata faza projekta
• prikupiti sve potrebne/dostupne informacije
• pružaju pravilno razumijevanje koncepata, praksi i teorije

• zakazane sastanke
• radionica posvećena početku projekta

Rezultati:

• detaljan plan konsultacija
• zajednički ciljevi
• pregled procesa

Faza 2: Analiza

Ciljevi faze analize su:

• analizu poslovnih i proizvodnih procesa u cilju:

Procijeniti spremnost osoblja koje servisira IT i sisteme automatizacije

Shvatite potrebe za podacima i funkcionalnošću za buduću arhitekturu

Identifikujte ključne prednosti buduće arhitekture za postavljanje ciljeva i implementaciju poslovnog slučaja

• analiza postojeće arhitekture

Utvrđivanje postojećih proizvodnih procesa u njihovoj povezanosti sa sistemima automatizacije, prikupljanjem podataka, sistemima upravljanja proizvodnjom

Identifikacija postojećih poslovnih procesa i njihova povezanost sa sistemima automatizacije proizvodnje

Identifikujte postojeće aplikacije, podatke, logičku i fizičku infrastrukturu i usluge tehničke podrške

Tokom ove faze provode se sljedeće aktivnosti:

• seminare i diskusije o raznim procesima
• posete sajtu radi dobijanja kontekstualnih informacija
• seminare i diskusije o postojećim sistemima
• procjenu usluga kako bi se utvrdila njihova zrelost i usklađenost sa regulatornim zahtjevima

Rezultati:

• identifikacija postojeće infrastrukture
• analitička dokumentacija
• lista ideja o izazovima i mogućnostima nove arhitekture lista ideja o izazovima i mogućnostima nove arhitekture

Faza 3: Cilj

Svrha ove faze je da identifikuje i opiše potrebe formulisane tokom faze analize.

Rješenje ili ciljna arhitektura će opisati:

• budući poslovni procesi i funkcionalnost
• ciljane vrste aplikacija, sa njihovom funkcionalnošću, korisnicima, informacijama i sučeljima
• infrastrukturne potrebe i revidirani standardi podrške

Tokom ove faze provode se sljedeće aktivnosti:

• seminari i diskusije o unapređenju procesa
• radionice i diskusije o poboljšanju arhitekture

Rezultati:

• buduća arhitektura (prezentacija)
• Kratak opis tipova aplikacija

Faza 4: Opravdanje

Svrha faze opravdanja je da pruži početni poslovni slučaj zasnovan na grubim procjenama troškova i koristi projekta.

Jaz između postojeće i željene situacije obično dovodi do pojave niza ideja. Opravdanje ideja će vam omogućiti da razlikujete “neophodno” od “poželjnog”, a nakon toga predstavite i razvijete ideje vrhunskom menadžmentu.

Tokom ove faze provode se sljedeće aktivnosti:

• gruba procjena troškova i koristi
• prva verzija prezentacije

Rezultati:

• zajednički ciljevi
• određivanje prioriteta poslovnih ideja
• procjena potrebnih resursa

Faza 5: Plan

Svrha ove faze je planiranje projekta na osnovu prioriteta, resursa i zavisnosti:

• planiranje redoslijeda implementacije faza konsolidovanog projekta
• obezbjeđivanje resursa i kompetencija potrebnih za naredne korake
• pokretanje aktivnosti upravljanja projektima
• završetak konsaltinga i prenos rezultata svih faza kupcu

Tokom ove faze provode se sljedeće aktivnosti:

• razvoj plana implementacije
• izradu investicionog plana
• procjena rizika

Rezultati:

• plan implementacije
• procjena obima posla osoblja uključenog u projekat
• procjena rizika projekta
• investicioni plan (kao prva aproksimacija)
• konačna verzija prezentacije projekta

Studija slučaja

Sljedeći primjer ilustruje primenu opisanog pristupa u realnim uslovima. Kako bi se ispunili uslovi povjerljivosti, u opisu se čuva anonimnost. Riječ je o prilično velikom poduzeću koje proizvodi aktivne sastojke za farmaceutske proizvode. Proizvodni pogoni su pušteni u rad prije više od 20 godina, a iako je od tada izvršena određena modernizacija, potrebno je zamijeniti jedan broj zastarjelih sistema. Sistemi za automatizaciju zgrada i DCS su na prvom mjestu, jer su bazirani na zastarjelim tehnologijama koje je teško održavati. Osim toga, proizvodnja se mora prilagoditi novim poslovnim zahtjevima, uključujući ukidanje nekih proizvoda i lansiranje drugih. Općenito, postoji potreba da se radi na planu migracije koji pokriva i tehničke i poslovne zahtjeve.

Prvo morate napraviti glavnu listu opreme koja se trenutno koristi u cijelom preduzeću. Ove informacije se često „skrivaju“ u raznim dokumentima (i sjećanjima zaposlenih). Mora se izdvojiti i vizualizirati tako da postane osnova za planiranje migracije. U tu svrhu obično kreiramo dijagram modula procesa koji prikazuje glavnu opremu i kretanje sirovina u svakoj proizvodnoj jedinici. Kao odvojeni slojevi "na vrhu" hardvera, pokazujemo koji sistemi podržavaju koji hardver.

Primjer je prikazan na sl. 2. Podaci o instaliranim sistemima se takođe nalaze u sistemskoj memoriji (ili jednostavno u Excel datotekama) i mogu se koristiti za dalju analizu i planiranje.

Slika 2. „Sloj“ automatizacije vam omogućava da procenite postojeće sisteme

Prije razmatranja plana migracije, potrebno je identificirati glavne poslovne razloge promjena u proizvodnji. U ovom slučaju, menadžment je identifikovao sljedeće motive:

1. Dosljedna usklađenost sa regulatornim zahtjevima bez grešaka

2. Minimalno vrijeme potrebno za ulazak na tržište, fleksibilnost

3. Uspjeh, konkurentnost, operativna izvrsnost

4. Beskompromisna kvaliteta

5. Rast obima proizvodnje

Ove ciljeve treba prevesti u konkretnije zadatke, čija se implementacija može kvantifikovati.

Zatim moramo saznati koliko dobro postojeći sistemi podržavaju tekuće i buduće poslovne procese. Da bismo to učinili, koristimo standardni referentni model (baziran na ANSI/ISA-95 seriji standarda). Uključuje 19 poslovnih procesa na visokom nivou, detaljno razrađenih do te mjere da vam omogućava da uvidite slabosti u njihovoj praktičnoj implementaciji i potrebu za promjenom zarad efikasnog poslovanja.

Pored toga, takođe treba da procenimo tehničke mogućnosti postojećih sistema za podršku poslovnih procesa u budućnosti. Ovo se radi sistematski, koristeći gore opisane informacije iz sistemske memorije. Za svaki sistem za koji se informacije nalaze u spremištu (u našem slučaju oko 70 sistema), potrebno je procijeniti sljedeće aspekte:

• Stanje opreme (istorija kvarova, srednje vrijeme između kvarova, starost opreme, dostupnost rezervnih dijelova)
• Status softvera (podrška dobavljača, dostupnost dokumentacije, osoblje sa potrebnim kompetencijama)
• Mogućnosti oporavka sistema (redundantnost, prosječan vijek trajanja prije popravke)
• Procjena uticaja na poslovanje (pružanje informacija, greške u podacima, nedostupnost)
• Indikativni indikatori (pouzdanost sistema, kritičnost sistema, itd.)

Tehničkom procjenom je utvrđena potreba za modernizacijom i zamjenom nekoliko sistema:

• Sistemi upravljanja procesima su bazirani na konvencionalnom, zastarelom DCS-u i mnogim različitim PLC-ovima, od kojih su neki već „zreli“ za zamjenu.
• Sistem automatizacije zgrada je baziran na novijoj platformi, ali također zahtijeva nadogradnju kako bi se ispunili novi zahtjevi.
• Brojni sekundarni sistemi također zahtijevaju modernizaciju, ili čak zamjenu.
• Infrastruktura koja opslužuje sve sisteme zahteva bolju segmentaciju i zaštitu kako bi zadovoljila današnje bezbednosne zahteve.

Dio III

Nakon analize poslovnih ciljeva za budućnost, postalo je očigledno da nijedan od postojećih sistema u potpunosti ne zadovoljava buduće potrebe. Ovo shvatanje je dalo povoda za niz ideja u vezi sa uvođenjem novih tehnologija, kao i sistema izvođenja proizvodnje. Kao rezultat analize, predloženo je 16 različitih projekata koji će, ukoliko se budu dosljedno implementirali, pomoći kompaniji da ispuni buduće tehničke i komercijalne zahtjeve.

Procjenjuje se sadržaj tehničkog rada i cijena svakog projekta; Za svaki projekat priprema se kratak sažetak na jednoj stranici o kojem će rukovodstvo raspravljati. (Vidi sliku 3).

Rice. 3. Opis potencijalnog projekta migracije na jednoj stranici

U cilju odabira prioritetnih projekata, procjenjuju se potencijalni rezultati svakog od njih. Rezultati se ocjenjuju u smislu poslovnih ciljeva, kao i pouzdanosti sistema upravljanja procesima.

Obično ćete morati procijeniti više scenarija implementacije da biste procijenili ukupne potrebe za resursima i finansiranjem za svaki plan (Slika 7). Jedno od glavnih ograničenja koje treba uzeti u obzir su prozori u proizvodnom procesu tokom kojih se sistemi mogu zamijeniti ili modificirati. Po pravilu, ovi „prozori“ se javljaju vikendom - i to je ozbiljno usko grlo.

Rice. 7. Konsolidovani pregled rasporeda migracije

Budući da uvijek ima malo vremena za zamjenu sistema i njihovo postavljanje, priprema mora biti vrlo temeljita. Sve mora biti detaljno isplanirano. Važan aspekt planiranja je testiranje implementiranih sistema.

U slučaju koji opisujemo, implementacija dugoročnog plana migracije provedena je u šest različitih tokova, vidi sl. 8.

Rice. 8. Organiziranje migracionih projekata u šest različitih tokova

Dio pripreme je temeljna procjena i prevencija projektnih rizika. Na sl. Slika 9 prikazuje tipične rizike povezane sa projektima migracije.

Rice. 9. Procjena tipičnih rizika migracionih projekata

Procesi poslovne podrške

Pristup upravljanja životnim ciklusom i dugoročnog planiranja migracije opisan u ovom članku vođen je poslovnim potrebama. Uključuje procjenu trenutnih i budućih poslovnih ciljeva, kao i detaljnu analizu načina na koji će tehnički sistemi biti održavani ili zamijenjeni kako bi najbolje podržali te ciljeve. Pristup se zasniva na principima TOGAF-a, koji predviđaju sekvencijalnu implementaciju projekta u zavisnosti od raspoloživosti budžeta i kvalifikovanog osoblja. Procjena trenutne i buduće arhitekture sistema je ključni element u određivanju budućih projekata migracije. Konačno, potrebno je pridržavati se principa upravljanja organizacijskim promjenama koji osiguravaju pravovremeno uključivanje ključnih aktera projekta, što je toliko važno za uspjeh migracionih projekata. Efikasnost ovog pristupa je više puta dokazana u praksi.

Leif Poulsen) ( ), vodeći stručnjak za automatizaciju i IT u NNE Pharmaplan. Magistrirao je procesni menadžment. U NNE Pharmaplanu, Poulsen je odgovoran za razvoj tehnologija, metoda i kompetencija u oblasti industrijske automatizacije i IT-a, te radi kao viši poslovni savjetnik.

Posljednje ažurirano: 31.10.2015

Često dolazi do situacije kada se model promijeni. Na primjer, odlučili smo uvesti nove nekretnine u njega. Ali u isto vrijeme, već imamo postojeću bazu podataka koja sadrži neke podatke. A kako bismo ažurirali bazu podataka bez gubitaka, ASP.NET MVC nam nudi takav mehanizam kao što su migracije. Na primjer, imamo jednostavan korisnički model:

Korisnik javne klase ( public int Id ( get; set; ) javni string Ime ( get; set; ) )

U skladu s tim, postoji kontekst podataka kroz koji radimo s bazom podataka:

Korisnici (dobi; postavi;))

I recimo da imamo svu infrastrukturu za rad sa ovim modelom - poglede, kontrolere i već imamo nekoliko objekata ovog modela u bazi podataka. Ali u nekom trenutku smo odlučili da promijenimo bazu modela aplikacije. Na primjer, dodali smo još jedno polje korisničkom modelu:

Public class User ( public int Id ( get; set; ) public string Ime ( get; set; ) public int Age ( get; set; ) )

Osim toga, odlučili smo dodati još jedan model, na primjer:

Javna klasa Kompanija ( public int Id ( get; set; ) javni string Ime ( get; set; ) )

Dakle, naš kontekst podataka se već mijenja na sljedeći način:

Javna klasa UserContext: DbContext ( javni UserContext() : base("DefaultConnection") ( ) javni DbSet Korisnici ( get; set; ) javni DbSet Kompanije (dobiti; postaviti; ) )

Pogledima za model User možemo dodati dodatno polje za svojstvo Age, možemo kreirati kontroler i poglede za novi model, ali kada pokušamo dodati novi objekt u bazu podataka, dobićemo grešku:

Kontekst podataka se promijenio i sada moramo preći sa stare šeme baze podataka na novu. I prije svega, pronađite prozor Package Manager Console na dnu Visual Studio-a, unesite naredbu u njega: enable-migrations i pritisnite Enter:

Nakon pokretanja ove naredbe Visual Studio, u projektu će biti kreirana mapa Migracije u kojoj možete pronaći datoteku Configuration.cs. Ova datoteka sadrži deklaraciju klase Configuration istog imena, koja postavlja postavke konfiguracije:

Imenski prostor MigrationApp.Migrations ( koristeći System; koristeći System.Data.Entity; koristeći System.Data.Entity.Migrations; koristeći System.Linq; interna zapečaćena klasa Konfiguracija: DbMigrationsConfiguration ( public Configuration() ( AutomaticMigrationsEnabled = false; ContextKey = "MigrationApp.Models.UserContext"; ) zaštićeno nadjačavanje void Seed(MigrationApp.Models.UserContext kontekst) ( ) ) )

U metodi Seed, možete inicijalizirati bazu podataka sa početnim podacima. Sada treba da kreiramo samu migraciju. Tamo, u konzoli upravitelja paketa, unesite naredbu:

PM Add-Migracija "MigrateDB"

Visual Studio će tada automatski generirati klasu migracije:

Imenski prostor MigrationApp.Migrations ( korištenjem System; korištenjem System.Data.Entity.Migrations; javna djelomična klasa MigrateDB: DbMigration (javno nadjačavanje void Up() ( CreateTable("dbo.Companies", c => new ( Id = c.Int( nullable: false, identity: true), Name = c.String(), )).PrimaryKey(t => t.Id("dbo.Users", "Age", c => c.Int(nullable); : false) ) javno nadjačavanje void Down() ( DropColumn("dbo.Users", "Age"); DropTable("dbo.Companies"); ) ) )

U metodi Up, pozivanjem metode CreateTable, kreira se tabela "dbo.Companies" i vrši se njena konfiguracija: kreiranje kolona, ​​podešavanje ključeva. I nova kolona Age se također dodaje postojećoj tabeli. Metoda Down uklanja kolonu i tabelu u slučaju da postoje. U stvari, ove metode su ekvivalentne izrazu ALTER u SQL-u, koji mijenja strukturu baze podataka i njenih tablica.

I na kraju, da bismo izvršili migraciju, primijenit ćemo ovu klasu upisivanjem naredbe u istu konzolu:

PM Update-Baza podataka

Nakon ovoga, ako pogledamo sastav baze podataka, vidjet ćemo da su na nju primijenjene promjene u skladu sa izvršenom migracijom:

Dakle, migracija je završena i već možemo koristiti ažurirane modele i kontekst podataka.

U ovom članku želimo sistematizirati naše iskustvo u provedbi migracije podataka u velikim korporativnim projektima vezanim za 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.

Termini i definicije

Migracija podataka se obično shvata kao konačna sekvenca rada, projekat koji ima za cilj jednokratno masovno kretanje podataka od izvornih sistema (istorijskih sistema) do odredišnog sistema. Istovremeno, eksploatacija ovih podataka u izvornim sistemima prestaje.

Migracija podataka mora se 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. 1

Istorijski sistemi- baze podataka kompanije Kupca, koje se planiraju u potpunosti ili djelimično zamijeniti prilikom implementacije novog sistema.

Sistem prijemnika- ciljni sistem, proizvoljna konfiguracija “1C:Enterprise 8”.

Početni podaci- podaci preuzeti sa istorijskih sistema u prilagođeni xls format datoteke. U ovom slučaju, čini se da je xls format jedan od najprikladnijih, jer je mogućnost učitavanja u xls datoteku prisutna u mnogim računovodstvenim sistemima „prethodnih generacija“.

Kao modernu alternativu kao transport, moguće je uzeti u obzir xml format datoteke.

Postoje i opcije za korištenje posredne baze podataka.

Transformacija, konverzija- proces pretvaranja izvornih podataka u podatke za učitavanje. Transformacija podataka se dešava u skladu sa šablonima za učitavanje. Rezultat transformacije su podaci koji se učitavaju.

Preuzmi podatke- podatke namijenjene za učitavanje u prijemni sistem. Ovaj članak, kao i izvorni podaci, razmatra xls format.

Šabloni podataka za učitavanje- opis tablica podataka koje treba učitati u ciljni sistem.

Faze migracije

Razmotrimo proces pripreme i provođenja migracije korak po korak.

Organizacione faze migracije uključuju sljedeće tačke:

· Definisanje strategije migracije. U ovoj fazi, Izvođač i Naručilac se dogovaraju o tehnologiji za obavljanje poslova migracije;

· 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 (na strani naručioca) i ciljnog sistema (na strani izvođača);

· Preliminarni plan migracije. Plan migracije će se nekoliko puta prilagođavati kako projekat bude napredovao;

· Periodi datuma za preuzimanje podataka iz istorijskih sistema, količine podataka. Granični periodi podataka za migracije, datumi testiranja i konačne migracije. Ove informacije se mogu pripisati planu migracije;

· Sastav podataka za migraciju. Referentni podaci, klasifikatori, podaci o transakcijama, stanja, promet, itd.;

· Pitanja provjere kvaliteta, ispravnosti i integriteta podataka tokom procesa migracije i na kraju;

· Problemi vraćanja na prethodno stanje u slučaju kvarova.

Pogledajmo bliže tehnološke faze migracije.

Rice. 2

1.Priprema šablona za učitavanje podataka

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 općenito cilja jednu ili više povezanih tablica na ciljnom ciljnom sistemu.

Šablon kaže:

· Opis svih polja xls datoteke podataka za preuzimanje, uključujući:

o Ime polja

o Indikator da se polje mora popuniti

o Primjer popunjavanja polja

o Napomena

· Opis pravila za učitavanje ciljne sistemske tabele na osnovu podataka koji se učitavaju (red u slučaju nekoliko povezanih tabela, algoritmi pretraživanja ključnih polja, itd.)

· Opis direktnog popunjavanja polja ciljnih sistemskih tabela ako je predviđeno bilo šta osim prenošenja podataka „jedan na jedan“ iz datoteke podataka za učitavanje. Relevantno za referentna polja, na primjer.

Tokom rada u ovoj fazi, Izvođač mora pripremiti i učitavač datoteke podataka za učitavanje. Kada radite sa xls datotekama, ovaj zadatak nije posebno težak.

2. Identifikacija izvora podataka

Ova faza može početi zajedno sa prethodnom fazom „1. Priprema šablona za učitavanje podataka."

U ovoj fazi, Kupčevi stručnjaci određuju iz kojih sistema i koji podaci se mogu preuzeti. Također biste trebali odrediti koji podaci Možda može biti potrebno.

U pravilu, u velikim migracijskim projektima, identificiranje kompletne iscrpne liste izvora podataka može potrajati dosta vremena i dešava se kako se rad nastavlja u narednim fazama.

Često se dešavaju situacije kada se, kako bi se dodatno osigurao integritet informacija, neki podaci moraju prenijeti iz štampanih izvora (digitalizirati) ili čak unijeti u tabele prema riječima ključnih zaposlenika Kupca.

Međutim, u ovoj fazi trebate pokušati identificirati što je moguće više potrebnih podataka.

3.Učitavanje izvornih podataka

Proces preuzimanja podataka sa istorijskih sistema može potrajati dosta vremena, posebno ako postoji mnogo sistema, različiti su i za njih su odgovorne različite divizije Korisnika. Ova tačka se mora uzeti u obzir tokom testa i konačnih 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.

Vrijedi napomenuti da iz ovog ili onog razloga (na primjer, sigurnosni problemi), Kupac u ovoj fazi ne može uvijek omogućiti preuzimanje podataka u potpunosti! Samo struktura podataka i nekoliko testnih pozicija. Dakle, može doći do situacije da će se tijekom testnih i završnih opterećenja u izvornim tablicama otkriti podaci niske kvalitete, što će dovesti do neplaniranih grešaka.

Da bi se ovaj problem sveo na najmanju moguću mjeru, potrebno je unaprijed dogovoriti obim preuzimanja testova iz istorijskih sistema.

4. Mapiranje podataka

Mapiranje (mapiranje podataka) - općenito, proces poređenja podataka iz istorijskih sistema i sistema koji prima. To jest, izvorni podaci i podaci koji se učitavaju.

Faza mapiranja je radno najintenzivnija faza i može zauzeti više od 50% cjelokupnog posla na zadatku migracije.

U ovoj fazi, cijela radna grupa projekta migracije je u potpunosti uključena.

U procesu mapiranja podataka potrebno je razlikovati podfaze mapiranja tablica i mapiranja polja.

· Mapiranje tabela, odnosno mapiranje šablona - poređenje tabela izvornih podataka i šablona podataka za učitavanje. Meč može biti 1:1 ili N:N. Kao rezultat ovog rada, sastavlja se i održava registar mapiranja tablica. Ova podetapa je neophodna za sljedeću podetapu kartiranja terena i za praćenje opšteg stanja u kartiranju.

Grupa 1C šablona	Naziv 1C predloška	Ime dokumenta- izvor	Pravila za generiranje izvorne datoteke	Odgovorno	Status	Bilješka
NSI	uzorak_ Nomenklatura	Nomenk latura.xls	Podesite izbor u sistemu N . Sačuvaj u txt . Otvorite u xls-u, kolone su tekst . Prvi red je zaglavlje . Broj kolona - 15 . Provjerite broj linija u txt i xls . Naziv lista je uvijek "Sheet1"	Ivanov I.I.	na poslu

· Mapiranje polja - mapiranje polja tabele unutar već definisanog mapiranja tabele. Rezultat ovog rada je registar mapiranja polja.

№pp

Cl. polje

Obavezno

Naziv polja 1C šablona “Nomenklatura_predloška”

Opis

Naziv polja "Nomenclature.xls"

Algoritam punjenja

Kod

Šifra elementa imenika

Kod

Ime

Ime

Da

Ova grupa

Sadrži jednu od sljedećih vrijednosti: . 1 - za grupe . 0 - za elemente

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.

5.Priprema pravila transformacije

Za razliku od prethodnih faza, ova faza je tehnička i uključuje rad izvođača radova.

Na osnovu dogovorenih registara mapiranja terena, stručnjaci Izvođača izrađuju pravila za transformaciju 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 (skriptova) za transformaciju podataka i okruženje za pretvaranje izvornih 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, koristeći standardnu ​​obradu 1C Query Console kao osnovu.

Obrada Query Console je poboljšana kako bi se omogućili direktni upiti za xls datoteke.

Evo primjera kombiniranja dvije izvorne xls datoteke Zaposleni.xls

Šifra zaposlenika	Prezime	Ime	Prezime	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 Priznanice:

Šifra zaposlenika	datum	Suma
	01.05.2004
	02.05.2004
	03.05.2004
	04.05.2004
2423Datum rođenja	Iznos računa	Otpisani iznos
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

Napominjemo 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 mogućnosti u odnosu na 1C jezik upita), kreira se početni upit koji izdvaja 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 veliku brzinu.

Rice. 3

2. Upit u 1C jeziku - glavni upit 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. Implementirano korištenjem skripte na 1C jeziku.

Na primjer, ovdje implementiramo dodavanje reda “TOTAL” u kolone iznosa.

4. Upišite konačni skup podataka u xls datoteku.

Općenito, izlaz su konačne datoteke za učitavanje u ciljnu 1C bazu podataka.

Ovaj alat vam također omogućava da spremite pravila konverzije podataka u zasebnu xml datoteku:

Osim toga, moguće je raditi V batch mod, što je posebno važno kada postoji velika količina heterogenih migrirajućih podataka.

U prethodnim fazama se uglavnom završava pripremni dio posla - identifikuju se svi izvori podataka, preuzimaju se izvorni podaci iz izvora, pripremaju se predlošci za preuzimanje u ciljnu bazu podataka, priprema mapiranje podataka i na kraju se razvijaju skripte za transformaciju podataka .

Treba napomenuti da prije konačne migracije svakako trebate provesti nekoliko testova. 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 kreiraju/ažuriraju konačni plan migracije

7. Usklađivanje podataka

Kvalitet preuzetih podataka treba provjeriti i nakon testnih migracija i na kraju završne migracije. Tokom usaglašavanja mogu se provjeriti sljedeći indikatori:

· Poklapanje ukupnih iznosa za bilanse, prema dokumentima;

· Kvantitativna podudaranja, na primjer broj OS;

· Ispravno popunjavanje pojedinačnih odabranih entiteta;

Imajte na umu da određene provjere migracijskih podataka i pitanja normalizacije podataka moraju biti riješeni tokom svih procesa 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. Može i treba da se izvrši na originalnim podacima;

· Prinuda tipova polja;

· Referentni integritet;

· Matematičke nedoslednosti. Na primjer, provjera praznih numeričkih polja na koja se planira podjela tokom transformacije;

· Općenito, provjera obavezna polja se popunjavaju;

· Zamjena netačnih znakova. Na primjer, engleski znakovi u ćiriličnim poljima (“o”, “a”, “e” itd.) Ovo posebno vrijedi za ključna polja!

· Provjera vrijednosti nizova polja za usklađenost sa tipovima prijemnog sistema (ograničenja dužine)

Nakon što je konačna migracija završena, prema unaprijed utvrđenoj strategiji migracije i planu migracije, donosi se odluka o daljem radu istorijskih sistema.

Često se operacija završi odmah nakon konačnog usaglašavanja podataka i evidentiranja uspjeha migracije – korisnici novog sistema više ne vode evidenciju u dva sistema paralelno, već se potpuno prebacuju na novi sistem. Istovremeno, pristup starom sistemu se održava u načinu čitanja.

U nekim slučajevima može doći do paralelnog rada dva sistema tokom trajanja probnog rada (TE) pa čak i nakon tog perioda. Pitanje paralelnog rada korisnika u dva sistema usko je povezano sa pitanjem mogućnosti vraćanja na stari sistem ukoliko se migracija (ili, generalno, rad novog sistema!) smatra nezadovoljavajućom.

Zaključak

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 vrlo radno intenzivan.

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, volumene baze podataka, itd., opća šema migracije izgleda gotovo identično.

• prenijeti postojeće domene resursa u organizacione jedinice novih domena, što će pojednostaviti upravljanje mrežnim resursima;
• “simulirati” napredak migracije, dok se pravi prijenos podataka ne dešava;
• poništiti preduzete radnje u vezi sa migracijom;
• premjestiti uslužne račune;
• restaurirati odnos poverenja između izvornog i ciljnog domena;
• Pretvorite više domena u jednu ili više velikih domena u već kreiranom okruženju Active Directory;
• restrukturirati postojeće grupe ili spojiti nekoliko grupa u jednu u ciljnoj domeni;
• analizirati proces prijenosa podataka evidentiranjem migracijskih događaja.

Migracija korisnika i radnih stanica u jedinstvenu Active Directory strukturu vrši se uz očuvanje postojećih prava pristupa.

Opcije nadogradnje

Postoje dvije glavne opcije za nadogradnju infrastrukture domene [4]:

• Ažuriranje domene. Ova metoda je najčešća i najlakša za implementaciju prilikom migracije domena. Ova metoda vam omogućava da sačuvate trenutnu strukturu domena, sistemske postavke, korisničku i grupnu strukturu. Ažuriranje domene (in-place update) uključuje prijenos postojećih kontrolera domena na novokreirani domen.
• Restrukturiranje domena. Ova metoda vam omogućava da promijenite postojeću strukturu domena, spojite domene ili pretvorite domene u organizacione jedinice.

Pored navedenih opcija, postoji i mješovita opcija zasnovana na njima - ažuriranje domena s njihovim naknadnim restrukturiranjem [13].

Ove opcije se zovu Putevi tranzicije za implementaciju Active Directory. Tranzicioni put odabran od njih će biti glavna karika u ukupnoj strategiji za ažuriranje infrastrukture domena. Ova strategija će uključivati ​​opis koje objekte usluge direktorija treba premjestiti i kojim redoslijedom. Najbolja praksa za bilo koje kretanje aplikacije tokom implementacije Active Directory je dokumentovanje svakog detalja u radnom dokumentu koji se zove plan tranzicije.

Kriterijumi za odabir tranzicionog puta

Prilikom odabira putanje tranzicije, pretpostavlja se da se odluka odnosi samo na jednu domenu, što znači da je savršeno fer koristiti različite puteve tranzicije za različite domene unutar iste organizacije.

Razmotrimo glavne kriterije koji se koriste pri odabiru najpogodnije tranzitne putanje [13], date u tabelama 12.1, 12.2, 12.3, 12.4, 12.5, 12.6.

• Kriterijum 1. Zadovoljstvo postojećim modelom postojećeg domena. Tabela 12.1. Odabir putanje prijelaza na osnovu kriterija 1

  Prijelazni put	Kriterijumi podobnosti
  Ažuriranje domene	Ako nema značajnih promjena koje biste željeli napraviti na modelu domene, tada će ažuriranje domene pružiti najlakši put. Naziv domene će ostati isti, kao i postojanje svih korisničkih i grupnih naloga
  Restrukturiranje domena	Ako trenutni model domena više ne zadovoljava organizacijske potrebe ili više nije najbolji za odjele organizacije, restrukturiranje domena može biti najbolji izbor.

• Kriterijum 2. Stepen rizika pri prelasku na novi model domena. Tabela 12.2. Odabir putanje prijelaza na osnovu kriterija 2

  Prijelazni put	Kriterijumi podobnosti
  Ažuriranje domene	Nadogradnja domene je metoda niskog rizika. Proces nadogradnje kontrolera domene je automatski, tako da ima malo prostora za greške bez interakcije korisnika. Metodologija za oporavak od neuspjele nadogradnje domene je također relativno jednostavna: ako nadogradnja ne uspije, morate isključiti primarni kontroler domene (PDC), dodijeliti bilo koji rezervni kontroler domene (BDC) koji ima svježe podatke ulozi PDC-a i ponovo započnite proceduru
  Restrukturiranje domena	Restrukturiranje domena je put većeg rizika od obnove domene. Ima još zadataka koje treba završiti, pa stoga mnogi procesi mogu poći po zlu. Kao rezultat toga, raste frustracija među korisnicima koji se ne mogu prijaviti, pristupiti potrebnim resursima ili pristupiti svojim poštanskim sandučićima.

• Kriterij 3. Vrijeme izvršenja prijelaza 1 Vrijeme tranzicije nije odlučujući faktor u odabiru puta tranzicije, ali može biti odlučujući faktor za male organizacije sa ograničenim resursima. .Tabela 12.3. Odabir putanje prijelaza na osnovu kriterija 3

  Prijelazni put	Kriterijumi podobnosti
  Ažuriranje domene	Obnavljanje domene je linearan proces: kada se jednom započne, mora se završiti. Zahtijeva manje koraka od restrukturiranja i stoga je potrebno manje vremena za završetak cijele tranzicije
  Restrukturiranje domena	Restrukturiranje domena uvijek traje duže. Na primjer, tokom restrukturiranja, puno vremena se troši na izgradnju i validaciju infrastrukture ciljnog domena, premještanje svih naloga sa izvornog domena na ciljni domen. Velike organizacije možda neće moći premjestiti sve objekte odjednom, pa se često restrukturiranje domena radi u nekoliko faza

• Kriterij 4: Vrijeme usluge imenika potrebno za završetak procesa migracije. Tabela 12.4. Odabir putanje prijelaza na osnovu kriterija 4

  Prijelazni put	Kriterijumi podobnosti
  Ažuriranje domene	Objekti naloga nisu dostupni tokom procesa migracije jer se sami ažuriraju kada se domena nadogradi
  Restrukturiranje domena	Dobar izbor za organizacije u kojima je radno vrijeme sistema kritična vrijednost. Budući da uključuje stvaranje nenaseljene, "čiste" šume i ostavlja originalno okruženje u suštini nepromijenjenim, funkcionalnost usluge imenika je očuvana kako korisnici nastavljaju funkcionisati u svom postojećem okruženju. Možete migrirati velike ili male grupe korisnika tokom sati van špica i ostaviti ove nove račune neaktivnima dok ne budete spremni da napustite stari sistem

• Kriterijum 5. Dostupnost resursa za završetak tranzicije. Tabela 12.5. Odabir putanje prijelaza na osnovu kriterija 5

  Prijelazni put	Kriterijumi podobnosti
  Ažuriranje domene	Budući da je ažuriranje domene automatizirana operacija, ovaj put prijelaza će zahtijevati manje ljudskih resursa
  Restrukturiranje domena	Restrukturiranje domena podrazumijeva više zadataka nego obnavljanje domene i stoga zahtijeva više resursa, što znači da mora biti adekvatno popunjeno da bi se nosilo s dodatnim opterećenjem povezanim s restrukturiranjem domena. Alternativa je da se dio ili cijeli projekat angažuje na vanjskim izvršiteljima: postoje mnoge konsultantske grupe koje su specijalizirane za takve projekte, štedeći vrijeme i novac potreban za obuku internog osoblja

• Kriterij 6. Budžet projekta tranzicije. Tabela 12.6. Odabir putanje prijelaza na osnovu kriterija 5

  Prijelazni put	Kriterijumi podobnosti
  Ažuriranje domene	Faktori koji doprinose smanjenju potrebnih budžetskih sredstava: mogućnost korištenja postojećeg serverskog hardvera; niži troškovi ljudskih resursa; smanjeni troškovi testiranja jer će biti potrebno testirati manje zadataka nadogradnje
  Restrukturiranje domena	Iz mnogo razloga, restrukturiranje domena će zahtijevati veći budžet od obnove domene. Hardverske zahtjeve potrebne za izgradnju golog šumskog okruženja u koje se moraju migrirati objekti usluga direktorija treba razmotriti iz perspektive budžeta

Ako kompanija ne ispunjava u potpunosti uslove da sa sigurnošću izabere obnovu domena ili restrukturiranje kao put obnove, ili ako joj oba puta odgovaraju, onda može izabrati treći put - obnovu domene nakon čega slijedi restrukturiranje.

Ovaj put do Active Directory-a će pružiti trenutne prednosti (delegiranje administracije, grupne politike, izdavanje aplikacija i drugo), kao i dugoročne prednosti restrukturiranja domena (manje domena sa povećanim obimom domena, dizajn domena u skladu sa poslovnim i organizacionim ciljevima kompanije).