Moderna företag står ofta inför behovet av att migrera sina informationssystem. Detta förfarande måste dock föregås av noggranna förberedelser, eftersom det finns många hinder på vägen.

Det kan finnas många anledningar till att påbörja övergången till ett nytt informationssystem (IS), inklusive att minska riskerna förknippade med driften av föråldrade plattformar, föra informationssystem till internationella standarder och öka effektiviteten i affärsprocesser. Men oavsett vilken uppgift företaget står inför måste övergången från en IP till en annan vara noggrant planerad och förberedd.

Migrationsproblem

När det kommer till migrering av transaktionssystem som ERP, fakturering, bearbetning eller kärnbank är övergången till ett nytt system mycket problematisk. Faktum är att IT-proffs måste säkerställa korrekt migrering av stora datamängder, upprätthålla parallell drift av gamla och nya system för avstämning och analys av resultaten.

Till exempel hade jag projekterfarenhet i en av de största bankerna, där ett transaktionssystem höll på att överföras från den inte längre stödda Informix-plattformen till Oracle-plattformen. Samtidigt var det nödvändigt att genomföra en grundlig analys av affärsprocesser, upprepade gånger överföra data från det gamla systemet till det nya och kontrollera konsekvensen av resultaten från de nya och gamla systemen, med hänsyn till varaktigheten av processföreskrifter. Därför var flytttiden 14 månader. Ibland kan parallell drift av två system fortsätta under en längre tid, men även när den är begränsad till flera månader, kräver att säkerställa driften av det nya IS tilldelning av ytterligare datorkraft och betydande tid för företagsanställda att samtidigt utföra uppgifter i två system .

Från avdelningssystem till företagsnivå

IP-uppdatering sker ofta inom ramen för globalisering och centralisering. Detta gör att du avsevärt kan minska kostnaderna för att stödja och uppdatera mjukvarusystem. Det är faktiskt mycket enklare att upprätthålla en enda plattform som betjänar alla anställda än att underhålla separata verktyg för varje avdelning. Till exempel, framgångsrik migrering av ett lagerredovisningssystem tillåter dig att överföra flera tusen avdelningar i en stor organisation till en enda plattform och ge en allvarlig minskning av IT-kostnaderna. Man bör dock komma ihåg att det mesta av förberedelserna i detta fall faller på samordning av data i olika format och representationer, utveckling av nya regler och konstruktion av nya modeller för medarbetarinteraktion.

En annan viktig aspekt är integrationsgränssnitt med andra företagsinformationssystem, särskilt självskrivna och specifika. Problem förknippade med dem kanske inte är så märkbara i det första skedet, men identifieras när man etablerar interaktion mellan olika avdelningar och det övergripande systemet. Och om för det gamla systemet sådana gränssnitt redan var implementerade programmatiskt eller organisatoriskt, så för det nya systemet kan de behöva utvecklas på nytt.

Man ska komma ihåg att tankar om att utöka funktionaliteten i systemet kan komma redan under genomförandet av projektet, precis som aptiten kommer under en måltid. Det innebär att det kommer att krävas en hel rad ytterligare arbeten.

Handlingsplan

Erfarenheterna från projektaktiviteter om systemmigrering visar att ett sådant projekt kräver noggranna förberedelser och måste åtföljas av en individuell plan. Men oavsett vilken typ av system som migreras, programvara, databasvolymer etc., ser det generella schemat nästan identiskt ut.

I det första skedet är det nödvändigt att genomföra en detaljerad granskning, ta reda på alla krav för driftsättet för det nya systemet, intervjua alla nyckelanvändare. Det är viktigt att förstå vilka mängder data och vilken typ av belastning vi pratar om, först då kommer specialister att kunna föreslå rätt migrationsstrategi.

Själva procedurerna måste också vara noggrant genomtänkta och innehålla så viktiga element som reglerna för användaråtkomst till system under migrering, rutiner för att återgå till ett tidigare tillstånd i händelse av misslyckanden och samverkan mellan de olika specialister som är involverade i dessa processer .

Efter överenskommelse med kunden görs vanligtvis en detaljerad plan som omfattar flera steg, nämligen: datakopiering, verifiering, parallelldrift av två system och en fullständig övergång till en ny plattform. Enligt min mening är det viktigaste i en professionellt organiserad systemmigrering smidigheten i processen för användare som gradvis utan stress kan börja arbeta i ett nytt automatiserat system.

Men även noggranna förberedelser räddar dig inte alltid från att underskatta arbetskostnaderna när du flyttar användare till "nya skenor." Denna process innefattar både utbildning av företagets anställda och deras stöd under anpassningsperioden till det nya systemet.

Leif Poulsen för InTech

System för automatisering av produktion och insamling av information om produktionsprocesser är relativt kortlivade. De måste ofta uppgraderas eller bytas ut innan processutrustningen når slutet av sin livslängd. För många företag är det en verklig utmaning att hantera utbyte eller uppgradering av sådana automationssystem utan att stoppa produktionen. Därför ignoreras det objektiva behovet av modernisering eller utbyte tills något händer. Den här artikeln handlar om hur du framgångsrikt kan utföra denna uppgift genom noggrann planering och organisation.

Två huvudfaktorer ligger bakom behovet av att modernisera och ersätta industriella automationssystem och industriella IT-system: den tekniska försämringen av dessa system, samt förändringar i kraven på de affärsprocesser som dessa system stödjer.

Tillförlitligheten hos tekniska system kommer att minska med tiden om företag ignorerar behovet av att modernisera operativsystem, databaser och applikationsprogram. Den operativa risken för utrustningsfel ökar i enlighet därmed.

Genom noggrann planering kan den operativa risken hållas på en acceptabel nivå, samtidigt som investeringarna skyddas och livscykelkostnaderna minimeras. För ett typiskt automations- eller IT-system går endast 20-40% av investeringen till inköp av systemet. Resterande 60-80 % går till att bibehålla dess höga tillgänglighet och anpassa sig till periodiskt förändrade krav.

Förutom att utvärdera de aktiviteter som krävs för att förhindra teknisk försämring är det nödvändigt att överväga nya utmaningar samt potentiella affärsmöjligheter. Affärsmiljön förändras ständigt och alla möjligheter att förbättra befintliga eller introducera ny teknik måste alltid övervägas. Typiska affärsmöjligheter som kan driva på migreringen av högkostnadsautomationssystem är snabbhet till marknaden, konkurrenskraft, tillväxt, kvalitet och regelefterlevnad.

Långsiktig migrationsplan

Genom att utveckla en långsiktig systemmigreringsplan kan företag upprätthålla systemiska operativa risker på en acceptabel nivå. Dessutom säkerställer det riskhantering och snabb support av affärsmål. Migreringsplanen måste ta hänsyn till restriktioner som "bästa tillverkningspraxis", teknisk funktionalitet och oundviklig produktionsstopp.

I allmänhet skildras tillvägagångssättet för långsiktig planering i fig. 1. En migrationsplan tas fram för att avgöra var företaget vill vara om fem år, vilka åtgärder som måste vidtas för att nå dit och om de resurser som krävs för att nå dit finns tillgängliga. Detta tillvägagångssätt är baserat på de arkitektoniska designprinciperna som beskrivs i TOGAF-standarden, som används i stor utsträckning i utvecklingen av systemarkitektur för industriföretag.

Figur 1. Allmänt tillvägagångssätt för att skapa en långsiktig migrationsplan.

Det är nödvändigt att skilja mellan den befintliga arkitekturen och det önskade målet. Skillnaden mellan dem speglar skillnaden mellan företagets nuvarande position och den position som det vill inta i framtiden. Migrationsplanen kartlägger vägen från den befintliga arkitekturen till målarkitekturen – eventuellt genom flera övergångssteg.

Varje arkitektur kan beskrivas som en serie "lager" som överbryggar gapet mellan affärer och teknik - som visas i figur 1. 1. Uppmärksamhet måste ägnas åt följande "lager":

• Affärsmål det är en del av den övergripande strategiplaneringen. De låter dig välja rätt riktning för processen.
• Affärsmodell ger ett sammanhang där produktion och affärsprocesser förstås. Vanligtvis innehåller den en beskrivning på hög nivå av materialflöden och processer.
• Beskrivning produktions- och affärsprocesserär viktigt för en framgångsrik tillämpning av teknologier och en korrekt bedömning av deras värde ur affärsmässig synvinkel.
• Information, data och dokument viktigt för att koppla samman processer och applikationer. Interoperabilitet och hantering av informationsflöden mellan applikationer är särskilt viktigt.
• Beskrivningar applikationer låter dig formulera krav på hög nivå och definiera gränssnitt.
• Definition infrastruktur, datorer och nätverk krav (hårdvara, feltolerans, prestanda).
• Försedd tjänster definiera krav för att säkerställa en effektiv verksamhetsstyrning och beslutsstöd.

Utarbeta en migrationsplan

Att utveckla en migreringsplan för en hel organisation, eller till och med en enda produktionsplats, kan vara en verkligt komplex uppgift som involverar många människor. Det rekommenderas att dela upp utvecklingsprocessen i flera steg, som beskrivs nedan.

Del II

Steg 1: Mobilisering

Grundläggande mål:

• uppnå en gemensam förståelse för uppgifter och mål
• mobilisera organisationen där projektet planeras
• detaljera planen genom att beskriva milstolpar och resultat av projektfaserna
• samla in all nödvändig/tillgänglig information
• ge en korrekt förståelse av begrepp, praktiker och teorier

• schemalagda möten
• workshop tillägnad projektets start

Resultat:

• detaljerad samrådsplan
• gemensamma mål
• processöversikt

Steg 2: Analys

Målen för analysfasen är:

• analys av affärs- och produktionsprocesser för att:

Bedöma beredskapen hos personal som servar IT- och automationssystem

Förstå data- och funktionalitetsbehoven för framtidens arkitektur

Identifiera nyckelfördelarna med den framtida arkitekturen för att sätta upp mål och implementera affärsfallet

• analys av befintlig arkitektur

Fastställande av befintliga produktionsprocesser i samband med automationssystem, datainsamling, produktionsledningssystem

Identifiering av befintliga affärsprocesser och deras kopplingar till produktionsautomationssystem

Identifiera befintliga applikationer, data, logisk och fysisk infrastruktur och tekniska supporttjänster

Under detta skede genomförs följande aktiviteter:

• seminarier och diskussioner om olika processer
• webbplatsbesök för att få kontextuell information
• seminarier och diskussioner om befintliga system
• utvärdera tjänster för att fastställa deras mognad och överensstämmelse med regulatoriska krav

Resultat:

• identifiering av befintlig infrastruktur
• analysdokumentation
• lista med idéer om den nya arkitekturens utmaningar och möjligheter lista med idéer om utmaningarna och möjligheterna med den nya arkitekturen

Steg 3: Mål

Syftet med detta steg är att identifiera och beskriva de behov som formulerats under analysskedet.

Lösningen, eller målarkitekturen, kommer att beskriva:

• framtida affärsprocesser och funktionalitet
• målapplikationstyper, med deras funktionalitet, användare, information och gränssnitt
• infrastrukturbehov och reviderade stödstandarder

Under detta skede genomförs följande aktiviteter:

• seminarier och diskussioner om processförbättringar
• workshops och diskussioner om att förbättra arkitekturen

Resultat:

• framtida arkitektur (presentation)
• Kort beskrivning av applikationstyper

Steg 4: Motivering

Syftet med motiveringsfasen är att tillhandahålla ett initialt affärscase baserat på grova uppskattningar av kostnaderna och fördelarna med projektet.

Gapet mellan den befintliga och den önskade situationen leder vanligtvis till uppkomsten av ett antal idéer. Motivering av idéer gör att du kan skilja "nödvändigt" från "önskvärt", och efter det presentera och utveckla idéer för högsta ledningen.

Under detta skede genomförs följande aktiviteter:

• grov uppskattning av kostnader och fördelar
• första versionen av presentationen

Resultat:

• gemensamma mål
• prioritering av affärsidéer
• bedömning av erforderliga resurser

Steg 5: Planera

Syftet med detta steg är att planera projektet utifrån prioriteringar, resurser och beroenden:

• planering av genomförandesekvensen av stadierna i ett konsoliderat projekt
• tillhandahålla de resurser och den kompetens som behövs för nästa steg
• initiering av projektledningsaktiviteter
• färdigställande av rådgivning och överföring av resultat av alla led till kund

Under detta skede genomförs följande aktiviteter:

• utveckling av en genomförandeplan
• utveckling av en investeringsplan
• riskbedömning

Resultat:

• implementationsplan
• bedömning av arbetsbördan för personal som är involverad i projektet
• projektriskbedömning
• investeringsplan (som en första uppskattning)
• slutversionen av projektpresentationen

Fallstudie

Följande exempel illustrerar tillämpningen av det beskrivna tillvägagångssättet i verkliga förhållanden. För att uppfylla sekretessvillkoren upprätthålls anonymitet i beskrivningen. Vi talar om ett ganska stort företag som producerar aktiva ingredienser för farmaceutiska produkter. Produktionsanläggningarna togs i drift för mer än 20 år sedan och även om en del modernisering har genomförts sedan dess kräver ett antal föråldrade system byte. Byggnadsautomationssystem och DCS är i första hand, eftersom de bygger på föråldrade tekniker som är svåra att underhålla. Dessutom måste produktionen anpassas till nya affärskrav, inklusive nedläggning av vissa produkter och lansering av andra. Generellt finns det ett behov av att arbeta med en migrationsplan som täcker både tekniska och affärsmässiga krav.

Först måste du skapa en huvudlista över den utrustning som för närvarande används i hela företaget. Denna information är ofta "dold" i olika dokument (och anställdas minnen). Den ska extraheras och visualiseras så att den blir grunden för migrationsplaneringen. För detta ändamål skapar vi vanligtvis ett processmoduldiagram som visar de viktigaste utrustningarna och råvarurörelserna i varje produktionsenhet. Som separata lager "ovanpå" hårdvaran visar vi vilka system som stöder vilken hårdvara.

Ett exempel visas i fig. 2. Data om installerade system finns också i systemlagringen (eller helt enkelt i Excel-filer), och kan användas för vidare analys och planering.

Figur 2. Automations "lager" låter dig utvärdera befintliga system

Innan man diskuterar en migrationsplan är det nödvändigt att identifiera de huvudsakliga affärsorsakerna till förändringar i produktionen. I det här fallet identifierade ledningen följande motiv:

1. Konsekvent och felfri efterlevnad av myndighetskrav

2. Minsta tid som krävs för att komma in på marknaden, flexibilitet

3. Framgång, konkurrenskraft, operationell excellens

4. Kompromisslös kvalitet

5. Tillväxt i produktionsvolymer

Dessa mål behöver översättas till mer specifika uppgifter, vars genomförande kan kvantifieras.

Därefter måste vi ta reda på hur väl befintliga system stödjer nuvarande och framtida affärsprocesser. För att göra detta använder vi en standardreferensmodell (baserad på ANSI/ISA-95-serien av standarder). Den innehåller 19 affärsprocesser på hög nivå, detaljerade i den mån det låter dig se svagheter i deras praktiska implementering och behovet av förändring för effektiv verksamhet.

Dessutom behöver vi också utvärdera den tekniska förmågan hos befintliga system för att stödja affärsprocesser i framtiden. Detta görs systematiskt med hjälp av informationen som beskrivs ovan från systemlagringen. För varje system för vilket information finns i förvaret (i vårt fall cirka 70 system) behöver följande aspekter bedömas:

• Utrustningens skick (felhistorik, genomsnittlig tid mellan fel, utrustningens ålder, reservdelstillgänglighet)
• Status för programvaran (leverantörssupport, tillgänglighet av dokumentation, personal med nödvändig kompetens)
• Systemåterställningsfunktioner (redundans, genomsnittlig livslängd före reparation)
• Affärskonsekvensbedömning (informationsförsörjning, datafel, otillgänglighet)
• Indikativa indikatorer (systemtillförlitlighet, systemkriticitet, etc.)

Den tekniska bedömningen identifierade behovet av att modernisera och ersätta ett antal system:

• Processkontrollsystem är baserade på en konventionell, föråldrad DCS och många olika PLC:er, av vilka några redan är "mogna" för utbyte.
• Byggnadsautomationssystemet bygger på en nyare plattform, men kräver också uppgradering för att möta nya krav.
• Ett antal sekundära system kräver också modernisering eller till och med utbyte.
• Infrastrukturen som betjänar alla system kräver bättre segmentering och skydd för att möta dagens säkerhetskrav.

Del III

Efter att ha analyserat affärsmålen för framtiden blev det uppenbart att inget av de befintliga systemen fullt ut uppfyller framtida behov. Denna förståelse gav upphov till ett antal idéer angående införandet av nya teknologier, såväl som produktionssystemet. Som ett resultat av analysen föreslogs 16 olika projekt som, om de genomförs konsekvent, kommer att hjälpa företaget att möta framtida tekniska och kommersiella krav.

Innehållet i det tekniska arbetet och kostnaden för varje projekt bedöms; För varje projekt görs en kort sammanfattning på en sida som ledningen kan diskutera. (Se figur 3).

Ris. 3. Ensidig beskrivning av ett potentiellt migreringsprojekt

För att välja prioriterade projekt utvärderas de potentiella resultaten av vart och ett av dem. Resultaten bedöms i termer av affärsmål, samt tillförlitligheten i processtyrningssystemet.

Vanligtvis kommer du att behöva utvärdera flera implementeringsscenarier för att uppskatta de övergripande resurs- och finansieringskraven för varje plan (Figur 7). En av de viktigaste begränsningarna att tänka på är fönstren i produktionsprocessen under vilka system kan bytas ut eller modifieras. Som regel förekommer dessa "fönster" på helgerna - och detta är en allvarlig flaskhals.

Ris. 7. Konsoliderad översikt över migreringsschemat

Eftersom det alltid finns lite tid att byta ut system och installera dem måste förberedelserna vara mycket noggranna. Allt måste planeras i detalj. En viktig aspekt av planeringen är att testa de implementerade systemen.

I det fall vi beskriver genomfördes implementeringen av den långsiktiga migrationsplanen i sex olika strömmar, se fig. 8.

Ris. 8. Organisera migrationsprojekt i sex olika strömmar

En del av förberedelserna är en noggrann bedömning och förebyggande av projektrisker. I fig. Figur 9 visar typiska risker förknippade med migrationsprojekt.

Ris. 9. Bedömning av typiska risker med migrationsprojekt

Affärsstödsprocesser

Tillvägagångssättet för livscykelhantering och långsiktig migrationsplanering som beskrivs i den här artikeln drivs av affärsbehov. Den inkluderar en bedömning av nuvarande och framtida affärsmål, samt en grundlig analys av hur tekniska system kommer att underhållas eller bytas ut för att på bästa sätt stödja dessa mål. Tillvägagångssättet är baserat på TOGAF-principer, som möjliggör sekventiellt projektgenomförande beroende på tillgången på budgetar och kvalificerad personal. Att bedöma nuvarande och framtida systemarkitekturer är ett nyckelelement för att fastställa framtida migreringsprojekt. Slutligen är det nödvändigt att följa principerna för organisatorisk förändringshantering som säkerställer att viktiga projektintressenter involveras i rätt tid, vilket är så viktigt för framgången för migrationsprojekt. Effektiviteten av detta tillvägagångssätt har upprepade gånger visat sig i praktiken.

Leif Poulsen) ( ), ledande automations- och IT-specialist på NNE Pharmaplan. Han har en magisterexamen i processledning. På NNE Pharmaplan ansvarar Poulsen för utvecklingen av teknologier, metoder och kompetenser inom området industriell automation och IT, och arbetar som senior affärskonsult.

Senast uppdaterad: 2015-10-31

Ofta uppstår en situation när modellen ändras. Vi beslutade till exempel att införa nya fastigheter i den. Men samtidigt har vi redan en befintlig databas som innehåller en del data. Och för att uppdatera databasen utan förlust, erbjuder ASP.NET MVC oss en sådan mekanism som migrering. Till exempel har vi en enkel användarmodell:

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

Följaktligen finns det ett datakontext genom vilket vi arbetar med databasen:

Användare(get;set;))

Och låt oss säga att vi har all infrastruktur för att arbeta med den här modellen - vyer, kontroller, och vi har redan flera objekt av denna modell i databasen. Men vid något tillfälle bestämde vi oss för att ändra applikationsmodellbasen. Till exempel har vi lagt till ett annat fält i användarmodellen:

Offentlig klass Användare ( public int Id ( get; set; ) public string Namn ( get; set; ) public int Ålder ( get; set; ) )

Dessutom bestämde vi oss för att lägga till ytterligare en modell, till exempel:

Public class Company ( public int Id ( get; set; ) public string Namn ( get; set; ) )

Således förändras vår datakontext redan enligt följande:

Public class UserContext: DbContext ( public UserContext() : base("DefaultConnection") ( ) public DbSet Användare ( get; set; ) public DbSet Företag ( get; set; ) )

Vi kan lägga till ett extra fält för egenskapen Age till vyerna för användarmodellen, vi kan skapa en kontroller och vyer för den nya modellen, men när vi försöker lägga till ett nytt objekt i databasen får vi ett felmeddelande:

Datakontexten har förändrats, och nu måste vi migrera från det gamla databasschemat till det nya. Och först av allt, hitta fönstret Package Manager Console längst ner i Visual Studio, ange kommandot i det: enable-migrations och tryck på Enter:

Efter att ha kört det här Visual Studio-kommandot skapas en Migrations-mapp i projektet, där du kan hitta filen Configuration.cs. Den här filen innehåller en deklaration av klassen Configuration med samma namn, som anger konfigurationsinställningarna:

Namespace MigrationApp.Migrations ( använder System; använder System.Data.Entity; använder System.Data.Entity.Migrations; använder System.Linq; intern förseglad klass Konfiguration: DbMigrationsConfiguration ( public Configuration() ( AutomaticMigrationsEnabled = false; ContextKey = "MigrationApp.Models.UserContext"; ) protected override void Seed(MigrationApp.Models.UserContext context) ( ) ) )

I Seed-metoden kan du initiera databasen med seed-data. Nu måste vi skapa själva migrationen. Där, i Package Manager Console, anger du kommandot:

PM Add-Migration "MigrateDB"

Visual Studio genererar sedan automatiskt en migreringsklass:

Namespace MigrationApp.Migrations ( använder System; använder System.Data.Entity.Migrations; offentlig delklass MigrateDB: DbMigration ( public override void Up() ( CreateTable("dbo.Companies", c => new ( Id = c.Int( nullable: false, identitet: true), Name = c.String(), )).PrimaryKey(t => t.Id); : false)); ) public override void Down() ( DropColumn("dbo.Users", "Age"); DropTable("dbo.Companies"); ) ) )

I Up-metoden, genom att anropa CreateTable-metoden, skapas tabellen "dbo.Companies" och dess konfiguration utförs: skapa kolumner, inställningsnycklar. Och en ny ålderskolumn läggs också till i den befintliga tabellen. Nedmetoden tar bort kolumnen och tabellen om de finns. Faktum är att dessa metoder är likvärdiga med ALTER-uttrycket i SQL, som ändrar strukturen på databasen och dess tabeller.

Och slutligen, för att utföra migreringen, kommer vi att tillämpa den här klassen genom att skriva kommandot i samma konsol:

PM Update-Databas

Efter detta, om vi tittar på databasens sammansättning, kommer vi att se att ändringar har tillämpats på den i enlighet med den utförda migreringen:

Så migreringen är klar och vi kan redan använda de uppdaterade modellerna och datakontexten.

I den här artikeln vill vi systematisera vår erfarenhet av att utföra datamigrering i stora företagsprojekt relaterade till övergången av kunder till arbete i 1C:Enterprise 8-konfigurationer.

Samtidigt kommer huvudvikten i artikeln först och främst att läggas på den tekniska komponenten i migrationsprocessen. Den organisatoriska delen påverkas också, men i mindre utsträckning.

Termer och definitioner

Datamigrering förstås vanligtvis som en slutlig arbetssekvens, ett projekt som syftar till en engångs massförflyttning av data från källsystem (historiska system) till destinationssystemet. Samtidigt upphör exploateringen av dessa data i källsystemen.

Datamigrering måste särskiljas från dataintegration. Integration är, till skillnad från migration, en permanent del av IT-arkitekturen och ansvarar för flödet av data mellan olika system och datalager – och är en process snarare än en projektaktivitet.

Migreringsschemat ser generellt ut så här:

Ris. 1

Historiska system- databaser över kundens företag, som planeras att helt eller delvis bytas ut vid implementering av ett nytt system.

Mottagare system- målsystem, godtycklig konfiguration "1C:Enterprise 8".

Inledande data- data som laddas ner från historiska system till ett anpassat xls-filformat. I det här fallet verkar xls-formatet vara ett av de mest bekväma, eftersom möjligheten att ladda upp till en xls-fil finns i många redovisningssystem av "tidigare generationer".

Som ett modernt alternativ som transport är det möjligt att överväga xml-filformatet.

Det finns också alternativ för att använda en mellanliggande databas.

Förvandling, omvandling- processen att konvertera källdata till data för laddning. Datatransformation sker i enlighet med laddningsmallar. Resultatet av transformationen är de data som ska laddas.

Ladda ner data- data avsedda att laddas in i det mottagande systemet. Den här artikeln, liksom källdata, tar hänsyn till xls-formatet.

Datamallar för laddning- Beskrivning av datatabeller som ska laddas in i målsystemet.

Migrationsstadier

Låt oss överväga processen att förbereda och genomföra migrering steg för steg.

De organisatoriska stadierna av migration inkluderar följande punkter:

· Definiera en migrationsstrategi. I detta skede kommer entreprenören och beställaren överens om tekniken för att utföra migreringsarbeten;

· Fastställande av sammansättningen av migrationsarbetsgruppen. I arbetsgruppen bör ingå specialister från både entreprenören och beställaren som är tillräckligt förtrogna med driften av historiska system (på beställarens sida) och målsystemet (på entreprenörens sida);

· Preliminär migrationsplan. Migrationsplanen kommer att justeras flera gånger allt eftersom projektet fortskrider;

· Perioder av datum för nedladdning av data från historiska system, datavolymer. Data cut-off perioder för migrering, datum för test och slutliga migrationer. Denna information kan hänföras till migrationsplanen;

· Sammansättning av data som ska migreras. Referensdata, klassificerare, transaktionsdata, saldon, omsättning, etc.;

· Frågor om kontroll av datas kvalitet, korrekthet och integritet under migreringsprocessen och i slutet;

· Problem med att rulla tillbaka till ett tidigare tillstånd vid fel.

Låt oss ta en närmare titt på migrationens tekniska stadier.

Ris. 2

1.Förbereda mallar för dataladdning

Dataladdningsmallen innehåller tekniska beskrivningar av de datatabeller som ska laddas, algoritmer och laddningsregler för den aktuella mallen.

Varje mall riktar sig i allmänhet mot en eller flera relaterade tabeller på målmålsystemet.

Mallen säger:

· Beskrivning av alla fält i xls-datafilen för nedladdning, inklusive:

o Fältnamn

o Indikator på att fältet måste fyllas i

o Exempel på att fylla i fältet

o Obs

· Beskrivning av reglerna för att ladda målsystemtabellen baserat på data som ska laddas (kö vid flera relaterade tabeller, sökalgoritmer för nyckelfält, etc.)

· Beskrivning av att fylla i fälten i målsystemtabellerna direkt om något annat än att överföra data "en till en" från en datafil för laddning tillhandahålls. Relevant för till exempel referensfält.

Under arbetet i detta skede ska Entreprenören även förbereda en datafilladdare för laddning. När du arbetar med xls-filer är denna uppgift inte särskilt svår.

2.Identifiering av datakällor

Detta steg kan börja tillsammans med föregående steg "1. Förbereder mallar för dataladdning."

I detta skede avgör kundens specialister från vilka system och vilken data som kan laddas ner. Du bör också bestämma vilken data Kanske kan behövas.

I stora migreringsprojekt kan det i regel ta ganska lång tid att identifiera en fullständig lista över datakällor och sker allt eftersom arbetet fortsätter i efterföljande etapper.

Det finns ofta situationer då, för att ytterligare säkerställa informationens integritet, vissa data måste överföras från tryckta källor (digitaliseras) eller till och med matas in i tabeller enligt orden från kundens nyckelmedarbetare.

Men i detta skede bör du försöka identifiera så mycket nödvändig information som möjligt.

3. Ladda upp källdata

Processen att ladda ner data från historiska system kan ta ganska lång tid, speciellt om det finns många system, de är olika och olika indelningar av kunden är ansvariga för dem. Denna punkt måste beaktas under test och slutlig migrering.

Det mest bekväma alternativet verkar vara att ladda upp till xls-filer. Många äldre IT-system stödjer detta alternativ.

Det kan också finnas alternativ för uppladdning till csv-format, dbf, xml-format och andra.

Det är värt att notera att kunden av en eller annan anledning (till exempel säkerhetsproblem) inte alltid kan tillhandahålla fullständiga datanedladdningar i detta skede! Bara en datastruktur och några testpositioner. Det kan alltså uppstå en situation att under test- och slutbelastningar kommer data av låg kvalitet att upptäckas i källtabellerna, vilket leder till oplanerade fel.

För att minimera detta problem bör volymen testnedladdningar från historiska system överenskommas i förväg.

4.Datamappning

Kartläggning (datamapping) - i allmänhet processen att jämföra data från historiska system och det mottagande systemet. Det vill säga källdata och data som ska laddas.

Kartläggningsskedet är det mest arbetsintensiva skedet och kan ta upp mer än 50 % av allt arbete med migrationsuppgiften.

I detta skede är hela migrationsprojektets arbetsgrupp helt involverad.

I processen för datakartläggning är det nödvändigt att skilja på delstadierna av tabellkartläggning och fältkartläggning.

· Kartläggning av tabeller, eller kartläggning av mallar - jämförelse av tabeller med källdata och datamallar för laddning. Matchen kan vara antingen 1:1 eller N:N. Som ett resultat av detta arbete kompileras och underhålls ett tabellmappningsregister. Detta delsteg är nödvändigt för nästa delsteg av fältkartläggning och för att övervaka det allmänna tillståndet i kartläggningen.

Grupp av 1C-mallar	Namn på 1C-mallen	Filnamn- källa	Regler för att skapa en källfil	Ansvarig	Status	Notera
NSI	Prov_ Nomenklatur	Nomenk latura.xls	Ställ in val i system N . Spara till txt . Öppna i xls, kolumner är text . Den första raden är rubriken . Antal kolumner - 15 . Kontrollera antalet rader i txt och xls . Arknamnet är alltid "Sheet1"	Ivanov I.I.	på jobbet

· Fältmappning - mappning av tabellfält inom en redan definierad tabellmappning. Resultatet av detta arbete är ett fältkarteringsregister.

№pp

Cl. fält

Nödvändig

1C mallfältnamn "Template_Nomenclature"

Beskrivning

Fältnamn "Nomenclature.xls"

Fyllningsalgoritm

Koda

Katalogelementkod

Koda

namn

namn

Ja

Denna grupp

Innehåller ett av följande värden: . 1 - för grupper . 0 - för element

Om kodens längd=11 tecken och de sista 4 tecknen<>"0000", då är detta element "0", annars är gruppen "1".

Fullständiga namn

Katalogelementnamn

namn

Om ThisGroup = 1, Då "", ElseIf ThisGroup = 0, sedan Namn.

Som en del av detta skede bör även eventuellt arbete med datanormalisering genomföras.

5.Förbereda omvandlingsregler

Till skillnad från de tidigare stegen är detta steg tekniskt och involverar entreprenörsutvecklarens arbete.

Utifrån de överenskomna fältkarteringsregistren utvecklar Entreprenörens specialister regler för datatransformation.

För operativt arbete under migreringens förberedande skeden och vidare, under test- och slutmigreringarna, är det viktigt att det finns en bekväm miljö för att utveckla regler (skript) för datatransformation och en miljö för att konvertera källdata till data för laddning.

Kraven för denna miljö inkluderar:

· Bekvämlighet och snabb utveckling av omvandlingsregler;

· Datakonverteringshastighet. In- och utdatafilerna kan vara hundratusentals rader långa!

· Förmåga att arbeta med flera indatafiler samtidigt;

· Möjlighet att spara transformationsregler i separata filer.

För våra migreringsprojekt har vi utvecklat en specialiserad arbetsstation för utvecklare som använder standardbehandlingen 1C Query Console som bas.

Query Console-behandlingen har förbättrats för att tillåta direkta frågor till xls-filer.

Här är ett exempel på att kombinera två käll-xls-filer Anställda.xls

Anställningskod	Efternamn	namn	Efternamn	Födelsedatum
2423	Ivanov	Ivan	Ivanovich	17.11.1992
1523	Petrov	Basilika	Aleksandrovich	04.02.1991
4363	Sidorov	Kirill	Nikolajevitj	01.05.1995
	Denisov	Denis	Denisovich	01.01.1990

Och Operationer.xls med sidor:

Avskrivningar

Anställningskod	datum	Belopp
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

Och Kvitton:

Anställningskod	datum	Belopp
	01.05.2004
	02.05.2004
	03.05.2004
	04.05.2004
2423Födelsedatum	Kvittobelopp	Avskrivet belopp
Ivanov Ivan Ivanovich	2423	17.11.1992	1341234	1010
Petrov Vasily Alexandrovich	1523	04.02.1991	245245
Denisov Denis Denisovich		01.01.1990	380000	320000
Sidorov Kirill Nikolaevich	4363	01.05.1995	613382	26336
TOTAL:			2579861	347842

Observera att exemplet är artificiellt, speciellt utvalt för att visa alla möjliga stadier av transformation av datakällor.

Den tekniska sekvensen av transformationsoperationer här är som följer:

Med hjälp av Access SQL-frågespråket (som ger betydande ytterligare möjligheter jämfört med 1C-frågespråket) skapas en första fråga som extraherar data från xls-filen till 1C-miljön. Samtidigt är olika kontroller och normalisering av data möjliga redan i detta skede.

ADO dataåtkomstteknik ger hög hastighet.

Ris. 3

2. Fråga på 1C-språk - huvudfrågan som implementerar fältmappningsalgoritmen. Och även: berikning av nedladdade data med data från 1C-databasen, omgruppering, sammanslagning med resultaten av frågor till andra xls-källfiler, etc.

3. Efterbearbetning av 1C-förfrågningsresultatet vid behov. Implementerat med ett skript i 1C-språk.

Till exempel implementerar vi här tillägget av "TOTAL"-raden i beloppskolumnerna.

4.Skriv den slutliga datamängden till en xls-fil.

I allmänhet är utdata slutfiler för laddning i mål 1C-databasen.

Detta verktyg låter dig också spara datakonverteringsregler i en separat xml-fil:

Dessutom går det att arbeta V batch-läge, vilket är särskilt viktigt när det finns en stor mängd heterogen migreringsdata.

Under de tidigare stegen avslutas i allmänhet den förberedande delen av arbetet - alla datakällor identifieras, källdata laddas ner från källorna, nedladdningsmallar förbereds i måldatabasen, datakartläggning förbereds och slutligen utvecklas datatransformationsskript .

Det bör noteras att innan den slutliga migreringen bör du definitivt utföra flera tester. Under testmigreringar identifierar entreprenören tillsammans med kunderna:

Konverteringsfel, dataladdningsfel

Gör en preliminär bedömning av kvaliteten på data som laddas in i målsystemet

Baserat på resultaten av testmigreringar skapar/uppdaterar de en slutlig migreringsplan

7.Dataavstämning

Kvaliteten på den nedladdade datan bör kontrolleras både efter testmigrering och i slutet av den slutliga migreringen. Under avstämningen kan följande indikatorer kontrolleras:

· Sammanfall av totala belopp för saldon, enligt dokument;

· Kvantitativa matchningar, till exempel antalet OS;

· Korrekt fyllning av enskilda utvalda enheter;

Observera att vissa kontroller av migrerande data och problem med datanormalisering måste lösas under alla migreringsprocesser. Du måste alltid fråga dig själv vad som behöver göras i det aktuella skedet för att undvika misstag i efterföljande etapper.

Till exempel:

· Kontrollera om det finns dubbletter av nyckelfält. Det kan och bör utföras på originaldata;

· Tvång av fälttyper;

· Referensintegritet;

· Matematiska inkonsekvenser. Till exempel, kontrollera om det finns tomma numeriska fält i vilka uppdelning planeras under transformation;

· I allmänhet fylls de obligatoriska fälten i;

· Ersättning av felaktiga tecken. Till exempel engelska tecken i kyrilliska fält ("o", "a", "e", etc.) Detta gäller särskilt för nyckelfält!

· Kontrollera värdena för strängfält för överensstämmelse med typerna av det mottagande systemet (längdbegränsningar)

Efter att den slutliga migreringen är klar, enligt en förutbestämd migrationsstrategi och migrationsplan, fattas beslut om den fortsatta driften av de historiska systemen.

Ofta slutförs operationen omedelbart efter de slutliga dataavstämningarna och registreringen av migreringens framgång - användare av det nya systemet för inte längre register i två system parallellt, utan byter helt till det nya systemet. Samtidigt bibehålls åtkomsten till det gamla systemet i läsläge.

I vissa fall kan parallelldrift av två system förekomma under provdriftens varaktighet (TE) och även efter denna period. Frågan om parallellt arbete av användare i två system är nära relaterat till frågan om möjligheten att återgå till det gamla systemet om migreringen (eller generellt sett driften av det nya systemet!) anses otillfredsställande.

Slutsats

Avslutningsvis vill jag notera att när det gäller att migrera stora transaktionssystem, som inkluderar många 1C:Enterprise-konfigurationer, kan övergången till ett nytt system vara mycket arbetskrävande.

Därför bör man komma ihåg att ett sådant projekt kräver noggrann förberedelse och måste åtföljas av en individuell plan. Men oavsett vilken typ av system som migreras, databasvolymer etc., ser det allmänna migreringsschemat nästan identiskt ut.

• överföra befintliga resursdomäner till organisatoriska enheter av nya domäner, vilket kommer att förenkla hanteringen av nätverksresurser;
• "simulera" migreringens framsteg, medan ingen riktig dataöverföring sker;
• ångra åtgärder som vidtagits i samband med migration;
• flytta tjänstekonton;
• Återställ förtroendefull relation mellan käll- och måldomäner;
• Konvertera flera domäner till en eller flera stora domäner i en redan skapad Active Directory-miljö;
• strukturera om befintliga grupper eller slå samman flera grupper till en i måldomänen;
• analysera dataöverföringsprocessen genom att logga migreringshändelser.

Migrering av användare och arbetsstationer till en enda Active Directory-struktur utförs samtidigt som befintliga åtkomsträttigheter bevaras.

Uppgraderingsalternativ

Det finns två huvudalternativ för att uppgradera domäninfrastrukturen [4]:

• Domänuppdatering. Denna metod är den vanligaste och enklaste att implementera vid migrering av domäner. Denna metod låter dig spara aktuell domänstruktur, systeminställningar, användar- och gruppstruktur. Domänuppdatering (på platsuppdatering) innebär överföring av befintliga domänkontrollanter till den nyskapade domänen.
• Domänomstrukturering. Med den här metoden kan du ändra den befintliga strukturen för domäner, slå samman domäner eller konvertera domäner till organisationsenheter.

Utöver alternativen ovan finns det också ett blandat alternativ baserat på dem - uppdatering av domäner med efterföljande omstrukturering [13].

Dessa alternativ kallas Övergångsvägar för Active Directory-implementering. Den övergångsväg som väljs bland dem kommer att vara huvudlänken i den övergripande strategin för uppdatering av domäninfrastrukturen. Denna strategi kommer att innehålla en beskrivning av vilka katalogtjänstobjekt som behöver flyttas och i vilken ordning. Den bästa praxisen för alla programflyttningar under en Active Directory-implementering är att dokumentera varje detalj i ett arbetsdokument som kallas en övergångsplan.

Kriterier för att välja övergångsväg

Vid val av övergångsväg förutsätts att beslutet endast gäller en domän, vilket innebär att det är helt rättvist att använda olika övergångsvägar för olika domäner inom samma organisation.

Låt oss överväga de viktigaste kriterierna som används när man väljer den mest lämpliga övergångsvägen [13], som ges i tabellerna 12.1, 12.2, 12.3, 12.4, 12.5, 12.6.

• Kriterium 1. Tillfredsställelse med den befintliga modellen för den befintliga domänen. Tabell 12.1. Välja en övergångsväg baserat på kriterium 1

  Övergångsväg	Urvalskriterier
  Domänuppdatering	Om det inte finns några betydande ändringar som du vill göra i domänmodellen, kommer uppdatering av domänen att ge den enklaste vägen. Domännamnet kommer att förbli detsamma, liksom förekomsten av alla användar- och gruppkonton
  Domänomstrukturering	Om den nuvarande domänmodellen inte längre uppfyller organisationens behov eller inte längre är den bästa passformen för organisationens avdelningar, kan domänomstrukturering vara det bästa valet.

• Kriterium 2. Graden av risk vid övergång till en ny domänmodell. Tabell 12.2. Välja en övergångsväg baserat på kriterium 2

  Övergångsväg	Urvalskriterier
  Domänuppdatering	Att uppgradera en domän är en lågriskmetod. Uppgraderingsprocessen för domänkontrollanten är automatisk, så det finns lite utrymme för fel utan användarinteraktion. Metodiken för att återhämta sig från ett domänuppgraderingsfel är också relativt enkel: om uppgraderingen misslyckas måste du stänga av den primära domänkontrollanten (PDC), tilldela alla backup-domänkontrollanter (BDC) som har färska data till PDC-rollen, och starta proceduren igen
  Domänomstrukturering	Domänomstrukturering är en högre riskväg än domänförnyelse. Det finns fler uppgifter att slutföra, och därför kan många processer gå fel. Som ett resultat växer frustration bland användare som inte kan logga in, komma åt nödvändiga resurser eller komma åt sina brevlådor.

• Kriterium 3. Övergång 1 exekveringstid Tidpunkten för övergången är inte en avgörande faktor för att välja en övergångsväg, men den kan vara en avgörande faktor för små organisationer med begränsade resurser. .Tabell 12.3. Välja en övergångsväg baserat på kriterium 3

  Övergångsväg	Urvalskriterier
  Domänuppdatering	Domänförnyelse är en linjär process: när den väl har påbörjats måste den slutföras. Det kräver färre steg än en omstrukturering och tar därför kortare tid att genomföra hela övergången
  Domänomstrukturering	Domänomstrukturering tar alltid längre tid. Till exempel, under en omstrukturering ägnas mycket tid åt att bygga och validera måldomänens infrastruktur, för att flytta alla konton från källdomänen till måldomänen. Stora organisationer kanske inte kan flytta alla objekt på en gång, så ofta görs omstrukturering av domänen i flera steg

• Kriterium 4: Katalogtjänsttid som krävs för att slutföra migreringsprocessen. Tabell 12.4. Välja en övergångsväg baserat på kriterium 4

  Övergångsväg	Urvalskriterier
  Domänuppdatering	Kontoobjekt är inte tillgängliga under migreringsprocessen eftersom de är självuppdaterade när domänen uppgraderas
  Domänomstrukturering	Ett bra val för organisationer där systemarbetstid är ett kritiskt värde. Eftersom det innebär att skapa en obefolkad, "ren" skog och lämnar den ursprungliga miljön i huvudsak oförändrad, bevaras funktionaliteten hos katalogtjänsten när användarna fortsätter att fungera i sin befintliga miljö. Du kan migrera stora eller små grupper av användare under lågtrafik och lämna dessa nya konton vilande tills du är redo att lämna det gamla systemet

• Kriterium 5. Tillgång till resurser för att slutföra övergången. Tabell 12.5. Välja en övergångsväg baserat på kriterium 5

  Övergångsväg	Urvalskriterier
  Domänuppdatering	Eftersom domänuppdateringen är en automatiserad operation kommer denna övergångsväg att kräva färre personalresurser
  Domänomstrukturering	Domänomstrukturering innebär fler uppgifter än domänförnyelse och kräver därför mer resurser, vilket innebär att den måste vara tillräckligt bemannad för att hantera den extra arbetsbelastning som är förknippad med domänomstrukturering. Ett alternativ är att lägga ut delar av eller hela projektet på entreprenad: det finns många konsultgrupper som är specialiserade på sådana projekt, vilket sparar tid och pengar som behövs för att utbilda intern personal

• Kriterium 6. Budget för övergångsprojekt. Tabell 12.6. Välja en övergångsväg baserat på kriterium 5

  Övergångsväg	Urvalskriterier
  Domänuppdatering	Faktorer som bidrar till en minskning av de nödvändiga budgetmedlen: förmåga att använda befintlig serverhårdvara; lägre personalkostnader; minskade testkostnader eftersom färre uppgraderingsuppgifter kommer att behöva testas
  Domänomstrukturering	Av många anledningar kommer domänomstrukturering att kräva en större budget än domänförnyelse. De hårdvarukrav som krävs för att bygga en barskogsmiljö till vilken katalogtjänstobjekt måste migreras bör övervägas ur ett budgetperspektiv

Om ett företag inte riktigt uppfyller villkoren för att med tillförsikt välja domänförnyelse eller omstrukturering som förnyelseväg, eller om båda vägarna är lämpliga för det, så kan det välja en tredje väg - domänförnyelse följt av omstrukturering.

Denna väg till Active Directory ger omedelbara fördelar (delegering av administration, grupppolicyer, applikationspublicering med mera), samt de långsiktiga fördelarna med domänomstrukturering (färre domäner med ökad domänvolym, domändesign i enlighet med företagets affärs- och organisationsmål).