Sodobna podjetja se pogosto srečujejo s potrebo po selitvi svojih informacijskih sistemov. Vendar pa je pred tem postopkom potrebna skrbna priprava, saj je na poti veliko ovir.

Razlogov za začetek prehoda na nov informacijski sistem (IS) je lahko zelo veliko, med drugim zmanjšanje tveganj, povezanih z delovanjem zastarelih platform, prilagoditev informacijskih sistemov mednarodnim standardom in povečanje učinkovitosti poslovnih procesov. A ne glede na nalogo, s katero se podjetje sooča, mora biti prehod z enega IP na drugega skrbno načrtovan in pripravljen.

Težave z migracijo

Ko gre za selitev transakcijskih sistemov, kot so ERP, obračunavanje, procesiranje ali osnovno bančništvo, je prehod na nov sistem zelo problematičen. Dejstvo je, da morajo IT strokovnjaki zagotoviti natančno migracijo velikih količin podatkov, ohranjati vzporedno delovanje starih in novih sistemov za usklajevanje in analizo rezultatov.

Imel sem na primer projektne izkušnje v eni največjih bank, kjer je potekal prenos transakcijskega sistema iz nepodprte več platforme Informix na platformo Oracle. Hkrati je bilo treba opraviti temeljito analizo poslovnih procesov, večkratno prenašati podatke iz starega sistema v novega ter preveriti konsistentnost rezultatov novega in starega sistema ob upoštevanju trajanja procesni predpisi. Zato je bila selitvena doba 14 mesecev. Včasih lahko vzporedno delovanje dveh sistemov traja dlje časa, a tudi ko je omejeno na več mesecev, zagotavljanje delovanja novega IS zahteva alokacijo dodatne računalniške moči in precejšnjega časa zaposlenih v podjetju za hkratno opravljanje nalog v dveh sistemih. .

Od sistema oddelkov do ravni podjetja

Posodabljanje IP pogosto poteka v okviru globalizacije in centralizacije. To vam omogoča znatno zmanjšanje stroškov podpore in posodabljanja programskih sistemov. Dejansko je vzdrževanje enotne platforme, ki služi vsem zaposlenim, veliko lažje kot vzdrževanje ločenih orodij za vsak oddelek. Na primer, uspešna migracija računovodskega sistema inventarja vam omogoča prenos več tisoč oddelkov velike organizacije na eno samo platformo in zagotovi resno zmanjšanje stroškov IT. Vendar ne smemo pozabiti, da večina priprav v tem primeru odpade na usklajevanje podatkov v različnih formatih in predstavitvah, razvoj novih predpisov in gradnjo novih modelov interakcije zaposlenih.

Drug pomemben vidik so integracijski vmesniki z drugimi informacijskimi sistemi podjetja, zlasti tistimi, ki jih pišejo sami in specifičnimi. Težave, povezane z njimi, na prvi stopnji morda niso tako opazne, vendar se ugotovijo pri vzpostavljanju interakcije med različnimi oddelki in celotnim sistemom. In če so bili za stari sistem takšni vmesniki programsko ali organizacijsko že implementirani, jih bo za nov sistem morda treba razviti na novo.

Ne smemo pozabiti, da lahko misli o razširitvi funkcionalnosti sistema pridejo že med izvajanjem projekta, tako kot apetit pride med obrokom. To pomeni, da bo potrebna cela vrsta dodatnega dela.

Akcijski načrt

Izkušnje projektnih aktivnosti na selitvi sistemov kažejo, da vsak tak projekt zahteva skrbno pripravo in mora biti opremljen z individualnim načrtom. Ne glede na vrsto sistemov, ki se selijo, programsko opremo, količine podatkovnih baz itd., je splošna shema videti skoraj enaka.

Na prvi stopnji je treba opraviti podrobno revizijo, ugotoviti vse zahteve za način delovanja novega sistema, opraviti razgovor z vsemi ključnimi uporabniki. Pomembno je razumeti, o kakšnih količinah podatkov in o kakšni obremenitvi govorimo, le tako bodo strokovnjaki lahko predlagali pravo strategijo migracije.

Tudi sami postopki morajo biti skrbno premišljeni in vključevati tako pomembne elemente, kot so pravila za uporabniški dostop do sistemov med migracijo, postopki za povrnitev na prejšnje stanje v primeru okvar in interakcija različnih strokovnjakov, ki sodelujejo pri teh procesih. .

Po dogovoru s stranko se običajno izdela natančen načrt, ki vključuje več faz, in sicer: kopiranje podatkov, preverjanje, vzporedno delovanje dveh sistemov in popoln prehod na novo platformo. Po mojem mnenju je glavna stvar pri profesionalno organizirani migraciji sistema gladkost procesa za uporabnike, ki lahko postopoma, brez stresa, začnejo delati v novem avtomatiziranem sistemu.

Vendar pa vas tudi skrbna priprava ne reši vedno pred podcenjevanjem stroškov dela pri prehodu uporabnikov na »nove tirnice«. Ta proces vključuje tako usposabljanje zaposlenih v podjetju kot njihovo podporo v obdobju prilagajanja na nov sistem.

Leif Poulsen za InTech

Sistemi za avtomatizacijo proizvodnje in zbiranje informacij o proizvodnih procesih so razmeroma kratkotrajni. Pogosto jih je treba nadgraditi ali zamenjati, preden se procesna oprema izteče. Za številna podjetja je obvladovanje zamenjave ali nadgradnje tovrstnih sistemov avtomatizacije brez ustavitve proizvodnje pravi izziv. Zato se objektivna potreba po posodobitvi ali zamenjavi ignorira, dokler se nekaj ne zgodi. Ta članek govori o tem, kako lahko s skrbnim načrtovanjem in organizacijo uspešno opravite to nalogo.

Dva glavna dejavnika sta v ozadju potrebe po posodobitvi in ​​zamenjavi sistemov industrijske avtomatizacije in industrijskih informacijskih sistemov: tehnična degradacija teh sistemov ter spremembe v zahtevah poslovnih procesov, ki jih ti sistemi podpirajo.

Zanesljivost tehničnih sistemov se bo sčasoma zmanjšala, če podjetja ne bodo upoštevala potrebe po posodobitvi operacijskih sistemov, baz podatkov in aplikacijske programske opreme. Temu primerno se poveča obratovalno tveganje okvare opreme.

S skrbnim načrtovanjem lahko operativno tveganje obdržimo na sprejemljivi ravni, hkrati pa zaščitimo naložbe in zmanjšamo stroške življenjskega cikla. Za tipičen sistem avtomatizacije ali IT gre samo 20-40 % naložbe za nakup sistema. Preostalih 60–80 % gre za vzdrževanje visoke razpoložljivosti in prilagajanje občasno spreminjajočim se zahtevam.

Poleg ocene potrebnih aktivnosti za preprečevanje tehnične degradacije je treba upoštevati nove izzive in potencialne poslovne priložnosti. Poslovno okolje se nenehno spreminja in vedno je treba upoštevati vse možnosti za izboljšanje obstoječih ali uvajanje novih tehnologij. Tipične poslovne priložnosti, ki lahko spodbudijo migracijo dragih sistemov za avtomatizacijo, so hitrost na trg, konkurenčnost, rast, kakovost in skladnost s predpisi.

Dolgoročni načrt selitve

Razvoj dolgoročnega načrta sistemske migracije omogoča podjetjem, da vzdržujejo sistemska operativna tveganja na sprejemljivi ravni. Poleg tega zagotavlja obvladovanje tveganj in pravočasno podporo poslovnim ciljem. Načrt migracije mora upoštevati omejitve, kot so »najboljše proizvodne prakse«, tehnološka funkcionalnost in neizogiben izpad proizvodnje.

Na splošno je pristop k dolgoročnemu načrtovanju prikazan na sliki 1. Načrt migracije je razvit, da se določi, kje želi podjetje biti v petih letih, katere ukrepe je treba sprejeti, da pride do tja, in ali so na voljo viri, potrebni za to. Ta pristop temelji na načelih arhitekturnega načrtovanja, opisanih v standardu TOGAF, ki se pogosto uporablja pri razvoju sistemske arhitekture za industrijska podjetja.

Slika 1. Splošni pristop k izdelavi dolgoročnega načrta migracije.

Treba je razlikovati med obstoječo arhitekturo in ciljno, želeno. Razlika med njima odraža razliko med trenutnim položajem podjetja in položajem, ki ga želi zasesti v prihodnosti. Načrt migracije začrta pot od obstoječe arhitekture do ciljne arhitekture – po možnosti skozi več prehodnih stopenj.

Vsako arhitekturo lahko opišemo kot niz "plasti", ki premostijo vrzel med poslovanjem in tehnologijo - kot je prikazano na sliki 1. 1. Pozornost je treba posvetiti naslednjim "plastem":

• Poslovni cilji je del celotnega prizadevanja za načrtovanje strategije. Omogočajo vam izbiro prave smeri procesa.
• Poslovni model zagotavlja kontekst, v katerem se razumejo proizvodni in poslovni procesi. Običajno vključuje opis materialnih tokov in procesov na visoki ravni.
• Opis proizvodnih in poslovnih procesov je pomembna za uspešno uporabo tehnologij in pravilno oceno njihove vrednosti s poslovnega vidika.
• Informacije, podatki in dokumenti pomembna za povezovanje procesov in aplikacij. Posebno pomembna je interoperabilnost in upravljanje informacijskih tokov med aplikacijami.
• Opisi aplikacije omogočajo oblikovanje zahtev na visoki ravni in definiranje vmesnikov.
• Opredelitev infrastruktura, računalništvo in omrežje zahteve (strojna oprema, toleranca napak, zmogljivost).
• Zagotovljeno storitve opredeliti zahteve za zagotavljanje učinkovitega operativnega vodenja in podpore odločanju.

Razvijanje načrta migracije

Razvijanje načrta selitve za celotno organizacijo ali celo posamezno proizvodno lokacijo je lahko resnično zapletena naloga, ki vključuje veliko ljudi. Priporočljivo je, da razvojni proces razdelite na več stopenj, opisanih spodaj.

del II

1. stopnja: mobilizacija

Osnovni cilji:

• doseči skupno razumevanje nalog in ciljev
• mobilizirati organizacijo, kjer je projekt načrtovan
• podrobno navedite načrt z opisom mejnikov in rezultatov faz projekta
• zbrati vse potrebne/razpoložljive informacije
• zagotoviti pravilno razumevanje konceptov, praks in teorije

• načrtovani sestanki
• delavnica, posvečena začetku projekta

Rezultati:

• podroben načrt posvetovanja
• skupni cilji
• pregled procesa

2. stopnja: Analiza

Cilji faze analize so:

• analiza poslovnih in proizvodnih procesov z namenom:

Ocenite pripravljenost osebja, ki servisira sisteme IT in avtomatizacijo

Razumeti potrebe po podatkih in funkcionalnosti za prihodnjo arhitekturo

Prepoznajte ključne prednosti prihodnje arhitekture za zastavljanje ciljev in izvedbo poslovnega primera

• analiza obstoječe arhitekture

Določanje obstoječih proizvodnih procesov v povezavi s sistemi avtomatizacije, zbiranjem podatkov, sistemi vodenja proizvodnje

Identifikacija obstoječih poslovnih procesov in njihove povezave s sistemi za avtomatizacijo proizvodnje

Identificirajte obstoječe aplikacije, podatke, logično in fizično infrastrukturo ter storitve tehnične podpore

V tej fazi se izvajajo naslednje dejavnosti:

• seminarji in razprave o različnih procesih
• obiski strani za pridobitev kontekstualnih informacij
• seminarji in razprave o obstoječih sistemih
• ocenjevanje storitev za določitev njihove zrelosti in skladnosti z regulativnimi zahtevami

Rezultati:

• identifikacijo obstoječe infrastrukture
• analizo dokumentacije
• seznam idej o izzivih in priložnostih nove arhitekture seznam idej o izzivih in priložnostih nove arhitekture

3. stopnja: cilj

Namen te stopnje je identificirati in opisati potrebe, oblikovane v fazi analize.

Rešitev ali ciljna arhitektura bo opisala:

• prihodnje poslovne procese in funkcionalnosti
• ciljne vrste aplikacij z njihovo funkcionalnostjo, uporabniki, informacijami in vmesniki
• infrastrukturne potrebe in spremenjene podporne standarde

V tej fazi se izvajajo naslednje dejavnosti:

• seminarji in razprave o izboljšanju procesov
• delavnice in razprave o izboljšanju arhitekture

Rezultati:

• prihodnja arhitektura (predstavitev)
• Kratek opis vrst aplikacij

Faza 4: Utemeljitev

Namen faze utemeljitve je zagotoviti začetni poslovni primer, ki temelji na grobih ocenah stroškov in koristi projekta.

Razkorak med obstoječo in želeno situacijo navadno vodi v nastanek številnih idej. Utemeljitev idej vam bo omogočila, da ločite "potrebno" od "zaželenega" in po tem predstavite in razvijete ideje najvišjemu vodstvu.

V tej fazi se izvajajo naslednje dejavnosti:

• groba ocena stroškov in koristi
• prva različica predstavitve

Rezultati:

• skupni cilji
• dajanje prednosti poslovnim idejam
• ocena potrebnih sredstev

5. stopnja: načrt

Namen te stopnje je načrtovanje projekta na podlagi prioritet, virov in odvisnosti:

• načrtovanje zaporedja izvedbe faz konsolidiranega projekta
• zagotavljanje virov in kompetenc, potrebnih za naslednje korake
• začetek dejavnosti projektnega vodenja
• zaključek svetovanja in prenos rezultatov vseh faz naročniku

V tej fazi se izvajajo naslednje dejavnosti:

• razvoj izvedbenega načrta
• razvoj investicijskega načrta
• ocena tveganja

Rezultati:

• izvedbeni načrt
• ocena obremenjenosti osebja, vključenega v projekt
• ocena tveganja projekta
• investicijski načrt (prvi približek)
• končna različica predstavitve projekta

Študija primera

Naslednji primer ponazarja uporabo opisanega pristopa v realnih razmerah. Zaradi izpolnjevanja pogojev zaupnosti je v opisu ohranjena anonimnost. Govorimo o dokaj velikem podjetju, ki proizvaja učinkovine za farmacevtske izdelke. Proizvodni obrati so bili zagnani pred več kot 20 leti in čeprav je bilo od takrat izvedenih nekaj posodobitev, je treba zamenjati številne zastarele sisteme. Sistemi za avtomatizacijo zgradb in DCS so na prvem mestu, saj temeljijo na zastarelih tehnologijah, ki jih je težko vzdrževati. Poleg tega se mora proizvodnja prilagoditi novim poslovnim zahtevam, vključno z ukinitvijo nekaterih izdelkov in lansiranjem drugih. Na splošno je treba delati na načrtu migracije, ki zajema tehnične in poslovne zahteve.

Najprej morate ustvariti glavni seznam opreme, ki se trenutno uporablja v celotnem podjetju. Ti podatki so pogosto »skriti« v različnih dokumentih (in spominih zaposlenih). Treba ga je izluščiti in vizualizirati, tako da postane osnova za načrtovanje migracij. V ta namen običajno ustvarimo diagram procesnega modula, ki prikazuje glavne premike opreme in surovin v vsaki proizvodni enoti. Kot ločene plasti "na vrhu" strojne opreme prikazujemo, kateri sistemi podpirajo katero strojno opremo.

Primer je prikazan na sl. 2. Podatki o nameščenih sistemih so shranjeni tudi v sistemskem pomnilniku (ali preprosto v Excelovih datotekah) in se lahko uporabljajo za nadaljnje analize in načrtovanje.

Slika 2. »Sloj« avtomatizacije vam omogoča ovrednotenje obstoječih sistemov

Pred razpravo o načrtu migracije je treba ugotoviti glavne poslovne razloge za spremembe v proizvodnji. V tem primeru je vodstvo identificiralo naslednje motive:

1. Dosledno in brezhibno izpolnjevanje regulativnih zahtev

2. Minimalni čas, potreben za vstop na trg, fleksibilnost

3. Uspešnost, konkurenčnost, operativna odličnost

4. Brezkompromisna kakovost

5. Rast obsega proizvodnje

Te cilje je treba prevesti v bolj specifične naloge, katerih izvajanje je mogoče kvantificirati.

Nato moramo ugotoviti, kako dobro obstoječi sistemi podpirajo sedanje in prihodnje poslovne procese. Za to uporabljamo standardni referenčni model (ki temelji na seriji standardov ANSI/ISA-95). Vključuje 19 visokonivojskih poslovnih procesov, ki so podrobno razčlenjeni do te mere, da lahko vidite slabosti v njihovi praktični implementaciji in potrebo po spremembi za učinkovito poslovanje.

Poleg tega moramo oceniti tudi tehnične zmožnosti obstoječih sistemov za podporo poslovnim procesom v prihodnosti. To se izvaja sistematično z uporabo zgoraj opisanih informacij iz sistemskega pomnilnika. Za vsak sistem, za katerega so informacije v repozitoriju (v našem primeru približno 70 sistemov), je treba oceniti naslednje vidike:

• Stanje opreme (zgodovina okvar, srednji čas med okvarami, starost opreme, razpoložljivost rezervnih delov)
• Status programske opreme (podpora prodajalca, razpoložljivost dokumentacije, osebje s potrebnimi kompetencami)
• Zmožnosti obnovitve sistema (redundanca, povprečna življenjska doba pred popravilom)
• Ocena učinka na poslovanje (zagotavljanje informacij, napake v podatkih, nedostopnost)
• Indikativni indikatorji (zanesljivost sistema, kritična pomembnost sistema itd.)

Tehnična ocena je pokazala potrebo po posodobitvi in ​​zamenjavi številnih sistemov:

• Sistemi za vodenje procesov temeljijo na običajnem, zastarelem DCS-ju in številnih različnih PLC-jih, od katerih so nekateri že »zreli« za zamenjavo.
• Sistem za avtomatizacijo stavb temelji na novejši platformi, vendar zahteva tudi nadgradnjo za izpolnjevanje novih zahtev.
• Tudi številni sekundarni sistemi potrebujejo posodobitev ali celo zamenjavo.
• Infrastruktura, ki služi vsem sistemom, zahteva boljšo segmentacijo in zaščito, da bi izpolnila današnje varnostne zahteve.

del III

Po analizi poslovnih ciljev za prihodnost je postalo očitno, da nobeden od obstoječih sistemov v celoti ne zadovoljuje prihodnjih potreb. Iz tega razumevanja so se porodile številne ideje o uvajanju novih tehnologij, pa tudi o sistemu izvedbe proizvodnje. Kot rezultat analize je bilo predlaganih 16 različnih projektov, ki bodo ob doslednem izvajanju podjetju pomagali izpolniti prihodnje tehnične in komercialne zahteve.

Ocenjuje se vsebina tehničnega dela in cena posameznega projekta; Za vsak projekt je pripravljen kratek enostranski povzetek, o katerem vodstvo razpravlja. (Glejte sliko 3).

riž. 3. Enostranski opis potencialnega migracijskega projekta

Za izbiro prednostnih projektov se ocenijo potencialni rezultati vsakega izmed njih. Rezultate ocenjujemo tako glede na poslovne cilje kot tudi glede na zanesljivost sistema vodenja procesov.

Običajno boste morali oceniti več scenarijev izvajanja, da ocenite splošne zahteve glede virov in financiranja za vsak načrt (slika 7). Ena od glavnih omejitev, ki jih je treba upoštevati, so okna v proizvodnem procesu, med katerimi je sisteme mogoče zamenjati ali spremeniti. Praviloma se ta "okna" pojavijo ob vikendih - in to je resno ozko grlo.

riž. 7. Konsolidiran pregled urnika selitve

Ker je časa za zamenjavo in postavitev sistemov vedno malo, morajo biti priprave zelo temeljite. Vse mora biti natančno načrtovano. Pomemben vidik načrtovanja je testiranje izvedenih sistemov.

V primeru, ki ga opisujemo, je bila izvedba dolgoročnega migracijskega načrta izvedena v šestih različnih tokovih, glej sl. 8.

riž. 8. Organiziranje migracijskih projektov v šestih različnih tokovih

Del priprave je temeljita ocena in preprečevanje projektnih tveganj. Na sl. Slika 9 prikazuje tipična tveganja, povezana z migracijskimi projekti.

riž. 9. Ocena tipičnih tveganj migracijskih projektov

Poslovni podporni procesi

Pristop upravljanja življenjskega cikla in načrtovanja dolgoročne migracije, opisan v tem članku, vodijo poslovne potrebe. Vključuje oceno sedanjih in prihodnjih poslovnih ciljev ter temeljito analizo o tem, kako bodo tehnični sistemi vzdrževani ali zamenjani za najboljšo podporo tem ciljem. Pristop temelji na načelih TOGAF, ki predvidevajo zaporedno izvedbo projekta glede na razpoložljivost proračuna in usposobljenega kadra. Ocena trenutne in prihodnje sistemske arhitekture je ključni element pri določanju prihodnjih migracijskih projektov. Nenazadnje se je treba držati načel upravljanja organizacijskih sprememb, ki zagotavljajo pravočasno vključevanje ključnih deležnikov projekta, kar je tako pomembno za uspeh migracijskih projektov. Učinkovitost tega pristopa je bila večkrat dokazana v praksi.

Leif Poulsen) ( ), vodilni strokovnjak za avtomatizacijo in IT pri NNE Pharmaplan. Je magister procesnega managementa. V NNE Pharmaplan je Poulsen odgovoren za razvoj tehnologij, metod in kompetenc na področju industrijske avtomatizacije in IT ter deluje kot višji poslovni svetovalec.

Zadnja posodobitev: 31. 10. 2015

Pogosto pride do situacije, ko se model spremeni. Odločili smo se na primer, da vanj uvedemo nove lastnosti. Toda hkrati že imamo obstoječo bazo, ki vsebuje nekaj podatkov. In da bi posodobili bazo podatkov brez izgube, nam ASP.NET MVC ponuja takšen mehanizem, kot so migracije. Na primer, imamo preprost uporabniški model:

Javni razred Uporabnik ( public int Id ( get; set; ) public string Name ( get; set; ) )

V skladu s tem obstaja kontekst podatkov, prek katerega delamo z bazo podatkov:

Uporabniki (dobi; nastavi;))

In recimo, da imamo vso infrastrukturo za delo s tem modelom - poglede, krmilnike in v bazi podatkov že imamo več objektov tega modela. Toda na neki točki smo se odločili spremeniti osnovo modela aplikacije. Uporabniškemu modelu smo na primer dodali še eno polje:

Javni razred Uporabnik ( public int Id ( get; set; ) public string Name ( get; set; ) public int Age ( get; set; ) )

Poleg tega smo se odločili dodati še en model, npr.

Javni razred Podjetje (javni int Id ( get; set; ) javni niz Ime ( get; set; ) )

Tako se kontekst naših podatkov že spreminja, kot sledi:

Javni razred UserContext: DbContext ( public UserContext() : base("DefaultConnection") ( ) public DbSet Uporabniki ( get; set; ) public DbSet Podjetja ( dobiti; nastaviti; ) )

Pogledom za uporabniški model lahko dodamo dodatno polje za lastnost Starost, ustvarimo lahko krmilnik in poglede za nov model, a ko poskušamo v bazo podatkov dodati nov objekt, bomo prejeli napako:

Kontekst podatkov se je spremenil in zdaj se moramo preseliti s stare sheme baze podatkov na novo. In najprej poiščite okno Package Manager Console na dnu Visual Studio, vanj vnesite ukaz: enable-migrations in pritisnite Enter:

Po zagonu tega ukaza Visual Studio bo v projektu ustvarjena mapa Migrations, kjer lahko najdete datoteko Configuration.cs. Ta datoteka vsebuje deklaracijo istoimenskega razreda konfiguracije, ki nastavi konfiguracijske nastavitve:

Imenski prostor MigrationApp.Migrations ( z uporabo System; z uporabo System.Data.Entity; z uporabo System.Data.Entity.Migrations; z uporabo System.Linq; notranja zapečatena konfiguracija razreda: DbMigrationsConfiguration ( public Configuration() ( AutomaticMigrationsEnabled = false; ContextKey = "MigrationApp.Models.UserContext"; ) protected override void Seed(MigrationApp.Models.UserContext context) ( ) ) )

V metodi Seed lahko bazo podatkov inicializirate s semenskimi podatki. Sedaj moramo ustvariti samo selitev. Tam v konzoli Package Manager Console vnesite ukaz:

PM Add-Migration "MigrateDB"

Visual Studio bo nato samodejno ustvaril selitveni razred:

Imenski prostor MigrationApp.Migrations ( using System; using System.Data.Entity.Migrations; javni delni razred MigrateDB: DbMigration ( javna preglasitev void Up() ( CreateTable("dbo.Companies", c => new ( Id = c.Int() nullable: false, identity: true), Name = c.String(), )).PrimaryKey(t => t.Id); AddColumn("dbo.Users", "Age", c => c.Int(nullable); : false)); javna preglasitev Down() ( DropColumn("dbo.Users", "Age"); DropTable("dbo.Companies"); ) )

Pri metodi Up se s klicem metode CreateTable ustvari tabela »dbo.Companies« in izvede njena konfiguracija: kreiranje stolpcev, nastavitev ključev. Obstoječi tabeli je dodan tudi nov stolpec Starost. Metoda Down odstrani stolpec in tabelo, če obstajata. Pravzaprav so te metode enakovredne izrazu ALTER v SQL, ki spremeni strukturo baze podatkov in njenih tabel.

In končno, za izvedbo selitve bomo ta razred uporabili tako, da v isto konzolo vnesemo ukaz:

PM Posodobljena baza podatkov

Po tem, če pogledamo sestavo baze podatkov, bomo videli, da so bile v njej uporabljene spremembe v skladu z opravljeno selitvijo:

Tako je selitev končana in že lahko uporabljamo posodobljene modele in podatkovni kontekst.

V tem članku želimo sistematizirati naše izkušnje pri izvajanju migracij podatkov v velikih korporativnih projektih, povezanih s prehodom strank na delo v konfiguracijah 1C:Enterprise 8.

Hkrati bo glavni poudarek v članku predvsem na tehnološki komponenti migracijskega procesa. Prizadeta je tudi organizacijska komponenta, vendar v manjši meri.

Izrazi in definicije

Migracija podatkov običajno razumemo kot končno zaporedje dela, projekt, katerega cilj je enkraten masovni premik podatkov iz izvornih sistemov (zgodovinskih sistemov) v ciljni sistem. Hkrati se preneha izkoriščanje teh podatkov v izvornih sistemih.

Migracijo podatkov je treba razlikovati od integracije podatkov. Integracija je za razliko od migracije stalni del IT-arhitekture in je odgovorna za pretok podatkov med različnimi sistemi in shrambami podatkov – in je bolj proces kot projektna aktivnost.

Shema migracije na splošno izgleda takole:

riž. 1

Zgodovinski sistemi- baz podatkov naročnikovega podjetja, ki jih je predvidena popolna ali delna zamenjava ob uvedbi novega sistema.

Sprejemni sistem- ciljni sistem, poljubna konfiguracija "1C:Enterprise 8".

Začetni podatki- podatki, preneseni iz zgodovinskih sistemov v datotečni format xls po meri. V tem primeru se zdi, da je format xls eden najbolj priročnih, saj je možnost nalaganja v datoteko xls prisotna v številnih računovodskih sistemih "prejšnjih generacij".

Kot sodobno alternativo je mogoče obravnavati format datoteke xml kot transport.

Obstajajo tudi možnosti uporabe vmesne baze podatkov.

Preobrazba, spreobrnjenje- proces pretvorbe izvornih podatkov v podatke za nalaganje. Preoblikovanje podatkov poteka v skladu s predlogami za nalaganje. Rezultat transformacije so podatki, ki jih je treba naložiti.

Podatki za prenos- podatke, namenjene nalaganju v sprejemni sistem. Ta članek in izvorni podatki obravnavajo format xls.

Predloge podatkov za nalaganje- opis podatkovnih tabel, ki se naložijo v ciljni sistem.

Stopnje selitve

Oglejmo si korak za korakom postopek priprave in izvedbe selitve.

Organizacijske stopnje migracije vključujejo naslednje točke:

· Opredelitev migracijske strategije. Na tej stopnji se izvajalec in naročnik dogovorita o tehnologiji izvajanja selitvenih del;

· Določitev sestave delovne skupine za migracije. Delovna skupina mora vključevati strokovnjake tako izvajalca kot naročnika, ki dovolj dobro poznajo delovanje zgodovinskih sistemov (na strani naročnika) in ciljnega sistema (na strani izvajalca);

· Preliminarni načrt selitve. Načrt selitve bo med potekom projekta večkrat prilagojen;

· Obdobja datumov za prenos podatkov iz zgodovinskih sistemov, količine podatkov. Obdobja preseka podatkov za selitve, datumi testa in končne selitve. Te informacije je mogoče pripisati načrtu selitve;

· Sestava podatkov za selitev. Referenčni podatki, klasifikatorji, transakcijski podatki, stanja, promet itd.;

· Problematika preverjanja kakovosti, pravilnosti in celovitosti podatkov v procesu migracije in na koncu;

· Težave pri vračanju na prejšnje stanje v primeru napak.

Oglejmo si podrobneje tehnološke faze migracije.

riž. 2

1.Priprava predlog za nalaganje podatkov

Predloga za nalaganje podatkov vsebuje tehnične opise podatkovnih tabel, ki jih je treba naložiti, algoritme in pravila nalaganja za trenutno predlogo.

Vsaka predloga na splošno cilja na eno ali več povezanih tabel v ciljnem ciljnem sistemu.

Predloga navaja:

· Opis vseh polj podatkovne datoteke xls za prenos, vključno z:

o Ime polja

o Indikator, da mora biti polje izpolnjeno

o Primer izpolnjevanja polja

o Opomba

· Opis pravil za nalaganje ciljne sistemske tabele na podlagi podatkov, ki jih je treba naložiti (čakalna vrsta v primeru več povezanih tabel, iskalni algoritmi za ključna polja itd.)

· Opis neposrednega izpolnjevanja polj ciljnih sistemskih tabel, če je na voljo karkoli drugega kot prenos podatkov »ena proti ena« iz podatkovne datoteke za nalaganje. Primerno za referenčna polja, na primer.

Med delom v tej fazi mora izvajalec za nalaganje pripraviti tudi nalagalnik podatkovnih datotek. Pri delu z datotekami xls ta naloga ni posebej težka.

2. Identifikacija virov podatkov

Ta stopnja se lahko začne skupaj s prejšnjo stopnjo “1. Priprava predlog za nalaganje podatkov."

Na tej stopnji naročnikovi strokovnjaki določijo, iz katerih sistemov in katere podatke je mogoče prenesti. Prav tako morate določiti, katere podatke mogoče morda bo potrebno.

Praviloma lahko pri velikih migracijskih projektih prepoznavanje popolnega izčrpnega seznama podatkovnih virov traja precej dolgo in se zgodi, ko se delo nadaljuje v naslednjih fazah.

Pogosto pride do situacij, ko je treba nekatere podatke za nadaljnje zagotavljanje celovitosti informacij prenesti iz tiskanih virov (digitalizirati) ali celo vnesti v tabele po besedah ​​naročnikovih ključnih zaposlenih.

Vendar pa morate na tej stopnji poskušati identificirati čim več potrebnih podatkov.

3. Nalaganje izvornih podatkov

Postopek prenosa podatkov iz zgodovinskih sistemov lahko traja precej časa, še posebej, če je sistemov veliko, so različni in so zanje odgovorni različni oddelki stranke. To točko je treba upoštevati med testnimi in končnimi migracijami.

Najbolj priročna možnost se zdi nalaganje v datoteke xls. Številni starejši sistemi IT podpirajo to možnost.

Obstajajo lahko tudi možnosti za nalaganje v formate csv, dbf, xml in druge.

Treba je opozoriti, da stranka zaradi enega ali drugega razloga (na primer varnostna vprašanja) na tej stopnji ne more vedno zagotoviti prenosa podatkov v celoti! Samo struktura podatkov in nekaj testnih položajev. Tako lahko pride do situacije, da bodo med preskusnimi in končnimi obremenitvami v izvornih tabelah odkriti podatki nizke kakovosti, kar bo povzročilo nenačrtovane napake.

Da bi zmanjšali to težavo, se je treba vnaprej dogovoriti o količinah testnih prenosov iz zgodovinskih sistemov.

4. Preslikava podatkov

Preslikava (preslikava podatkov) - na splošno postopek primerjave podatkov iz zgodovinskih sistemov in prejemnega sistema. To so izvorni podatki in podatki, ki jih je treba naložiti.

Stopnja preslikave je najbolj delovno intenzivna stopnja in lahko zavzame več kot 50 % vsega dela pri nalogi selitve.

Na tej stopnji je v celoti vključena celotna delovna skupina projekta migracije.

V procesu preslikave podatkov je potrebno razlikovati podstopnji preslikave tabel in preslikave polj.

· Preslikava tabel ali preslikava predlog - primerjava tabel izvornih podatkov in podatkovnih predlog za nalaganje. Tekma je lahko 1:1 ali N:N. Kot rezultat tega dela se prevede in vzdržuje register preslikav tabel. Ta podstopnja je potrebna za naslednjo podstopnjo kartiranja polja in za spremljanje splošnega stanja kartiranja.

Skupina predlog 1C	Ime predloge 1C	Ime datoteke- vir	Pravila za generiranje izvorne datoteke	Odgovorno	Stanje	Opomba
NSI	vzorec_ Nomenklatura	Nomenk latura.xls	Nastavite izbor v sistemu N . Shrani v txt . Odprto v xls, stolpci so besedilo . Prva vrstica je glava . Število stolpcev - 15 . Preverite število vrstic v txt in xls . Ime lista je vedno "Sheet1"	Ivanov I.I.	na delu

· Preslikava polj - preslikava polj tabele v okviru že definirane preslikave tabele. Rezultat tega dela je register kartiranja polj.

št

Cl. polje

Obvezno

Ime polja predloge 1C "Nomenklatura_predloge"

Opis

Ime polja "Nomenklatura.xls"

Algoritem polnjenja

Koda

Koda elementa imenika

Koda

Ime

Ime

ja

Ta skupina

Vsebuje eno od naslednjih vrednosti: . 1 - za skupine . 0 - za elemente

Če je dolžina kode=11 znakov in zadnji 4 znaki<>"0000", potem je ta element "0", sicer je skupina "1".

Polno ime

Ime elementa imenika

Ime

If ThisGroup = 1, then "", ElseIf ThisGroup = 0, then Name.

V okviru te faze naj bi potekala tudi morebitna dela na normalizaciji podatkov.

5.Priprava transformacijskih pravil

Za razliko od prejšnjih stopenj je ta stopnja tehnična in vključuje delo razvijalca izvajalca.

Izvajalčevi strokovnjaki na podlagi dogovorjenih registrov kartiranja polj razvijejo pravila za transformacijo podatkov.

Za operativno delo med pripravljalnimi fazami migracije in naprej, med testnimi in končnimi migracijami, je pomembno, da obstaja priročno okolje za razvoj pravil (skript) za transformacijo podatkov in okolje za pretvorbo izvornih podatkov v podatke za nalaganje.

Zahteve za to okolje vključujejo:

· Priročnost in hitrost razvoja transformacijskih pravil;

· Hitrost pretvorbe podatkov. Vhodne in izhodne datoteke so lahko dolge več sto tisoč vrstic!

· Sposobnost dela z več vhodnimi datotekami hkrati;

· Sposobnost shranjevanja pravil transformacije v ločene datoteke.

Za naše migracijske projekte smo razvili specializirano razvijalsko delovno postajo, na kateri je kot osnova uporabljena standardna obdelava 1C Query Console.

Obdelava konzole Query Console je bila izboljšana, da omogoča neposredne poizvedbe do datotek xls.

Tukaj je primer združevanja dveh izvornih datotek xls Zaposleni.xls

Koda zaposlenega	Priimek	Ime	Priimek	Datum rojstva
2423	Ivanov	Ivan	Ivanovič	17.11.1992
1523	Petrov	Bazilika	Aleksandrovič	04.02.1991
4363	Sidorov	Kiril	Nikolajevič	01.05.1995
	Denisov	Denis	Denisovich	01.01.1990

in Operacije.xls s stranmi:

Odpisi

Koda zaposlenega	datum	vsota
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

in Prejemki:

Koda zaposlenega	datum	vsota
	01.05.2004
	02.05.2004
	03.05.2004
	04.05.2004
2423Datum rojstva	Znesek prejema	Odpisani znesek
Ivanov Ivan Ivanovič	2423	17.11.1992	1341234	1010
Petrov Vasilij Aleksandrovič	1523	04.02.1991	245245
Denisov Denis Denisovič		01.01.1990	380000	320000
Sidorov Kiril Nikolajevič	4363	01.05.1995	613382	26336
SKUPAJ:			2579861	347842

Upoštevajte, da je primer umeten, posebej izbran za prikaz vseh možnih stopenj transformacije podatkovnih virov.

Tehnološko zaporedje operacij preoblikovanja je naslednje:

Z uporabo poizvedovalnega jezika Access SQL (ki nudi znatne dodatne zmogljivosti v primerjavi s poizvedovalnim jezikom 1C) se ustvari začetna poizvedba, ki izvleče podatke iz datoteke xls v okolje 1C. Hkrati so že v tej fazi možna različna preverjanja in normalizacije podatkov.

Tehnologija dostopa do podatkov ADO zagotavlja visoko hitrost.

riž. 3

2. Poizvedba v jeziku 1C - glavna poizvedba, ki izvaja algoritem za preslikavo polj. In tudi: obogatitev prenesenih podatkov s podatki iz baze podatkov 1C, prerazvrščanje, združevanje z rezultati poizvedb v druge izvorne datoteke xls itd.

3. Po potrebi naknadna obdelava rezultata zahteve 1C. Izvedeno s skriptom v jeziku 1C.

Na primer, tukaj izvajamo dodajanje vrstice »SKUPAJ« v stolpce zneskov.

4. Končni nabor podatkov zapišite v datoteko xls.

Na splošno so izhod končne datoteke za nalaganje v ciljno bazo podatkov 1C.

To orodje vam omogoča tudi shranjevanje pravil za pretvorbo podatkov v ločeni datoteki xml:

Poleg tega je mogoče delati V paketni način, kar je še posebej pomembno, kadar obstaja velika količina heterogenih selitvenih podatkov.

V prejšnjih fazah se pripravljalni del dela praviloma konča - identificirajo se vsi viri podatkov, prenesejo izvorni podatki iz virov, pripravijo se predloge za prenos v ciljno bazo podatkov, pripravi se preslikava podatkov in na koncu se razvijejo skripte za transformacijo podatkov. .

Upoštevati je treba, da morate pred končno selitvijo opraviti več testov. Med testnimi migracijami izvajalec skupaj s strankami identificira:

Napake pri pretvorbi, napake pri nalaganju podatkov

Izvedite predhodno oceno kakovosti podatkov, naloženih v ciljni sistem

Na podlagi rezultatov testnih migracij izdelajo/posodabljajo končni načrt migracije

7. Usklajevanje podatkov

Kakovost prenesenih podatkov je treba preveriti po testnih migracijah in ob koncu končne migracije. Med usklajevanjem je mogoče preveriti naslednje kazalnike:

· Sovpadanje skupnih zneskov za stanja, glede na dokumente;

· Kvantitativna ujemanja, na primer število OS;

· Pravilno izpolnjevanje posameznih izbranih entitet;

Upoštevajte, da je treba določena preverjanja podatkov o selitvi in ​​težave z normalizacijo podatkov rešiti v vseh postopkih selitve. Vedno se morate vprašati, kaj je treba storiti v trenutni fazi, da se izognete napakam v naslednjih fazah.

Na primer:

· Preverite dvojnike po ključnih poljih. Lahko in mora biti izvedeno na izvirnih podatkih;

· Prisiljevanje tipov polj;

· Referenčna celovitost;

· Matematične nedoslednosti. Na primer, preverjanje praznih številskih polj, v katera je predvidena razdelitev med transformacijo;

· Na splošno velja, da so obvezna polja za preverjanje izpolnjena;

· Zamenjava nepravilnih znakov. Na primer angleški znaki v poljih v cirilici (»o«, »a«, »e« itd.) To še posebej velja za ključna polja!

· Preverjanje vrednosti polj nizov za skladnost z vrstami prejemnega sistema (omejitve dolžine)

Po končani končni selitvi se po vnaprej določeni migracijski strategiji in načrtu selitve sprejme odločitev o nadaljnjem delovanju zgodovinskih sistemov.

Pogosto se operacija zaključi takoj po končnih uskladitvah podatkov in beleženju uspešnosti migracije – uporabniki novega sistema ne vodijo več evidenc v dveh vzporednih sistemih, ampak popolnoma preidejo na nov sistem. Hkrati se dostop do starega sistema ohranja v načinu branja.

V nekaterih primerih lahko pride do vzporednega delovanja dveh sistemov v času trajanja poskusnega obratovanja (TE) in celo po tem obdobju. Vprašanje vzporednega dela uporabnikov v dveh sistemih je tesno povezano z vprašanjem možnosti vrnitve nazaj na stari sistem, če je selitev (ali na splošno delovanje novega sistema!) ocenjena kot nezadovoljiva.

Zaključek

Na koncu bi rad omenil, da je pri selitvi velikih transakcijskih sistemov, ki vključujejo veliko konfiguracij 1C:Enterprise, prehod na nov sistem lahko zelo naporen.

Zato je treba zapomniti, da vsak tak projekt zahteva skrbno pripravo in ga mora spremljati individualni načrt. Vendar pa je splošna shema selitve videti skoraj enaka, ne glede na vrsto sistemov, ki se selijo, količine baze podatkov itd.

• prenos obstoječih domen virov v organizacijske enote novih domen, kar bo poenostavilo upravljanje omrežnih virov;
• »simulirajte« potek migracije, medtem ko ne pride do pravega prenosa podatkov;
• razveljavi sprejete ukrepe v zvezi z migracijo;
• premik storitvenih računov;
• obnoviti zaupljiv odnos med izvorno in ciljno domeno;
• Pretvorite več domen v eno ali več velikih domen v že ustvarjenem okolju Active Directory;
• prestrukturirati obstoječe skupine ali združiti več skupin v eno v ciljni domeni;
• analizirati proces prenosa podatkov z beleženjem migracijskih dogodkov.

Migracija uporabnikov in delovnih postaj v enotno strukturo Active Directory se izvaja ob ohranjanju obstoječih pravic dostopa.

Možnosti nadgradnje

Obstajata dve glavni možnosti za nadgradnjo domenske infrastrukture [4]:

• Posodobitev domene. Ta način je najpogostejši in najlažji za implementacijo pri selitvi domen. Ta metoda vam omogoča shranjevanje trenutne strukture domene, sistemskih nastavitev, strukture uporabnikov in skupin. Posodobitev domene (posodobitev na mestu) vključuje prenos obstoječih krmilnikov domene v novo ustvarjeno domeno.
• Prestrukturiranje domene. Ta način omogoča spreminjanje obstoječe strukture domen, združevanje domen ali pretvorbo domen v organizacijske enote.

Poleg zgornjih možnosti obstaja tudi mešana možnost, ki temelji na njih - posodobitev domen z njihovim naknadnim prestrukturiranjem [13].

Te možnosti se imenujejo Prehodne poti za implementacijo Active Directory. Prehodna pot, izbrana med njimi, bo glavna povezava v celotni strategiji za posodobitev domenske infrastrukture. Ta strategija bo vključevala opis, katere objekte imeniške storitve je treba premakniti in v kakšnem vrstnem redu. Najboljša praksa za kakršno koli premikanje aplikacije med implementacijo imenika Active Directory je dokumentiranje vseh podrobnosti v delovnem dokumentu, imenovanem načrt prehoda.

Kriteriji za izbiro prehodne poti

Pri izbiri prehodne poti se predpostavlja, da se odločitev nanaša samo na eno domeno, kar pomeni, da je povsem pošteno uporabiti različne prehodne poti za različna področja znotraj iste organizacije.

Oglejmo si glavne kriterije, ki se uporabljajo pri izbiri najprimernejše prehodne poti [13], podane v tabelah 12.1, 12.2, 12.3, 12.4, 12.5, 12.6.

• Merilo 1. Zadovoljstvo z obstoječim modelom obstoječe domene. Tabela 12.1. Izbira prehodne poti na podlagi 1. merila

  Prehodna pot	Merila primernosti
  Posodobitev domene	Če ni bistvenih sprememb, ki bi jih želeli narediti v modelu domene, bo posodobitev domene zagotovila najlažjo pot. Ime domene bo ostalo enako, prav tako obstoj vseh uporabniških in skupinskih računov
  Prestrukturiranje domene	Če trenutni model domene ne izpolnjuje več organizacijskih potreb ali ni več najbolj primeren za oddelke organizacije, je morda najboljša izbira prestrukturiranje domene.

• Merilo 2. Stopnja tveganja pri prehodu na nov domenski model. Tabela 12.2. Izbira prehodne poti na podlagi merila 2

  Prehodna pot	Merila primernosti
  Posodobitev domene	Nadgradnja domene je metoda z nizkim tveganjem. Postopek nadgradnje krmilnika domene je samodejen, tako da je malo prostora za napake brez interakcije uporabnika. Metodologija za obnovitev po neuspešni nadgradnji domene je prav tako razmeroma preprosta: če nadgradnja ne uspe, morate zaustaviti primarni krmilnik domene (PDC), dodeliti rezervni krmilnik domene (BDC), ki ima sveže podatke, vlogi PDC in znova zaženite postopek
  Prestrukturiranje domene	Prestrukturiranje domene je pot z večjim tveganjem kot podaljšanje domene. Nalog, ki jih je treba opraviti, je več, zato gre lahko veliko procesov narobe. Posledično narašča razočaranje med uporabniki, ki se ne morejo prijaviti, dostopati do potrebnih virov ali svojih poštnih predalov.

• Merilo 3. Čas izvedbe prehoda 1 Čas prehoda ni odločilen dejavnik pri izbiri poti prehoda, vendar je lahko odločilni dejavnik za majhne organizacije z omejenimi viri. .Tabela 12.3. Izbira prehodne poti na podlagi merila 3

  Prehodna pot	Merila primernosti
  Posodobitev domene	Podaljšanje domene je linearen proces: ko se začne, ga je treba dokončati. Zahteva manj korakov kot prestrukturiranje in zato traja manj časa za dokončanje celotnega prehoda
  Prestrukturiranje domene	Prestrukturiranje domene vedno traja dlje. Na primer, med prestrukturiranjem se veliko časa porabi za izgradnjo in potrjevanje infrastrukture ciljne domene, s premikanjem vseh računov iz izvorne domene v ciljno domeno. Velike organizacije morda ne bodo mogle premakniti vseh objektov naenkrat, zato prestrukturiranje domene pogosto poteka v več fazah.

• Merilo 4: Čas imeniške storitve, potreben za dokončanje postopka selitve. Tabela 12.4. Izbira prehodne poti na podlagi merila 4

  Prehodna pot	Merila primernosti
  Posodobitev domene	Objekti računa med postopkom selitve niso na voljo, ker se ob nadgradnji domene samodejno posodobijo
  Prestrukturiranje domene	Dobra izbira za organizacije, v katerih je sistemski delovni čas kritična vrednost. Ker vključuje ustvarjanje nenaseljenega, "čistega" gozda in pušča izvirno okolje v bistvu nespremenjeno, se funkcionalnost imeniške storitve ohrani, saj uporabniki še naprej delujejo v obstoječem okolju. Velike ali majhne skupine uporabnikov lahko preselite med urami izven obremenitve in pustite te nove račune v mirovanju, dokler niste pripravljeni zapustiti starega sistema

• Merilo 5. Razpoložljivost virov za dokončanje prehoda. Tabela 12.5. Izbira poti prehoda na podlagi merila 5

  Prehodna pot	Merila primernosti
  Posodobitev domene	Ker je posodobitev domene avtomatizirana operacija, bo ta prehodna pot zahtevala manj človeških virov
  Prestrukturiranje domene	Prestrukturiranje domene vključuje več nalog kot obnova domene in zato zahteva več sredstev, kar pomeni, da mora biti ustrezno kadrovsko opremljena za obvladovanje dodatne obremenitve, povezane s prestrukturiranjem domene. Druga možnost je, da del ali celoten projekt oddate zunanjim izvajalcem: obstaja veliko svetovalnih skupin, ki so specializirane za takšne projekte, s čimer prihranite čas in denar, potreben za usposabljanje notranjega osebja.

• Merilo 6. Proračun projekta prehoda. Tabela 12.6. Izbira poti prehoda na podlagi merila 5

  Prehodna pot	Merila primernosti
  Posodobitev domene	Dejavniki, ki prispevajo k zmanjšanju potrebnih proračunskih sredstev: možnost uporabe obstoječe strežniške strojne opreme; nižji stroški človeških virov; znižani stroški testiranja, saj bo treba preizkusiti manj nalog nadgradnje
  Prestrukturiranje domene	Zaradi številnih razlogov bo prestrukturiranje domene zahtevalo večji proračun kot podaljšanje domene. Zahteve glede strojne opreme, potrebne za izgradnjo golega gozdnega okolja, v katerega je treba preseliti objekte imeniške storitve, je treba upoštevati s proračunskega vidika

Če podjetje ne izpolnjuje povsem pogojev, da bi kot pot podaljšanja samozavestno izbralo podaljšanje ali prestrukturiranje domene oziroma mu obe poti ustrezata, lahko izbere tretjo pot - podaljšanje domene s prestrukturiranjem.

Ta pot do imenika Active Directory bo zagotovila takojšnje koristi (prenos upravljanja, skupinske politike, objavljanje aplikacij in drugo), ter dolgoročne prednosti prestrukturiranja domene (manj domen s povečanim obsegom domene, oblikovanje domene v skladu s poslovnimi in organizacijskimi cilji podjetja).