Systeemmigratie. Fasen van het datamigratieproces in IS-implementatieprojecten

De service voor het migreren van een bestaand IT-servicevan HP OpenView Service Desk 4.5/5.x is gericht op het oplossen van de volgende taken:

• het verminderen van operationele risico's door over te stappen op een product dat volledig wordt ondersteund door de ontwikkelaar en zijn partners in de Russische Federatie;
• het verminderen van migratierisico's, het verminderen van de kosten en tijd van migratie door over te stappen op een oplossing die ideologisch zo dicht mogelijk bij HP OpenView Service Desk 4.5/5.x ligt (vereist geen serieuze herwerking van bestaande processen en volledige herscholing van personeel);
• het waarborgen van de mogelijkheid van verdere ontwikkeling van IT-beheerpraktijken door de functionele beperkingen te overwinnen die inherent zijn aan het huidige automatiseringssysteem.

Migratie wordt uitgevoerd naar een gespecialiseerde projectoplossing OMNITRACKER CleverENGINE, geïmplementeerd op basis van het OMNITRACKER-platform. Deze oplossing biedt klanten de volgende belangrijke voordelen:

• CleverENGINE is vanaf de basis ontworpen om zo compatibel mogelijk te zijn met HP OpenView Service Desk en zo een soepele migratie-ervaring te bieden. CleverENGINE heeft een vergelijkbaar datamodel en hetzelfde principe voor het organiseren van de gebruikersinterface. Hierdoor kunt u tijdens de migratie moeite en geld besparen op gedwongen aanpassingen aan bestaande beheerprocessen, het omscholen van personeel en blijft er ook de mogelijkheid over om historische gegevens over te dragen;
• CleverENGINE is ontworpen en gebouwd door bestaande IT-beheerconsultants. De functionaliteit van CleverENGINE is aanzienlijk beter dan die van HP OpenView Service Desk. Het biedt met name CMDB-visualisatie, boekhouding en controle over het gebruik van softwarelicenties, releasebeheer, onderhoud van de kennisbank, automatisering van regelgevende activiteiten, een krachtig goedkeuringsmechanisme en nog veel meer. Hierdoor kunnen klanten hun IT-beheerpraktijken verbeteren door de functionele beperkingen van het huidige automatiseringssysteem te overwinnen;
• Het OMNITRACKER-platform is een omgeving voor de snelle ontwikkeling van verschillende workflow-applicaties (ook die buiten het bereik van IT-servicemanagement). Oplossingen op basis van OMNITRACKER worden in de regel in open vorm aan klanten overgedragen - beschikbaar voor aanpassing en verdere ontwikkeling. Veel klanten ontwikkelen hun automatiseringssystemen zelfstandig, met weinig of geen hulp van partners. Tegelijkertijd is het op basis van één platform mogelijk om geleidelijk functionaliteit te ontwikkelen die traditioneel inherent is aan verschillende producten: servicebeheer, projectbeheer, documentbeheer en andere oplossingen.

Als onderdeel van de migratie wordt een onderzoek naar het huidige automatiseringssysteem uitgevoerd en worden er introductieseminars over CleverENGINE gehouden voor het sleutelpersoneel van de klant. Op basis van de resultaten worden de vereisten voor de uiteindelijke oplossing verduidelijkt en worden kansen geïdentificeerd om snel voordelen te behalen door het gebruik van kant-en-klare CleverENGINE-functionaliteit die voorheen niet beschikbaar was. Vervolgens wordt een nieuw automatiseringssysteem gebouwd, worden kwalificatietests uitgevoerd en wordt het personeel opgeleid. Vervolgens worden, indien nodig, historische gegevens overgedragen en overgezet naar een nieuw automatiseringssysteem. Hierna krijgt de klant technische ondersteuning tijdens het proefdraaien. Na voltooiing van het project wordt het automatiseringssysteem overgedragen naar industriële exploitatie.

resultaten

Als resultaat van het migratieproject ontvangt de klant:

• een nieuw automatiseringssysteem met behoud van de beheerprocessen die in het oude automatiseringssysteem werkten;
• nieuwe functionaliteit van het automatiseringssysteem die voorheen niet beschikbaar was;
• een set Russischtalige gebruikersdocumentatie voor het nieuwe automatiseringssysteem.

Typisch projectprofiel

De duur van het migratieproject varieert van 2,5 tot 4,5 maanden - afhankelijk van de mate van “maatwerk” van het bestaande systeem op basis van HP OpenView Service Desk (aantal bedrijfslogische regels, formulieren en dataweergaven, rapportage, integratieoplossingen, enz. ), evenals de noodzaak om historische gegevens over te dragen. Het project wordt uitgevoerd door 1-2 specialisten. Specialisten met vakkennis van beide producten – HP OpenView Service Desk en OMNITRACKER CleverENGINE – zijn bij de werkzaamheden betrokken.

De dienst voor het migreren van een bestaand IT servicemanagement automatiseringssysteem kan worden uitgevoerd voor systemen geïmplementeerd op basis van diverse softwareproducten. Afhankelijk van het product waaruit u migreert, ontvangt de klant verschillende voordelen en vereist het project verschillende bronnen. Tegelijkertijd blijft de algemene logica van de werkorganisatie behouden.

Voorbeelden van gerealiseerde projecten

Voorbeelden van projecten uitgevoerd door Cleverics consultants:

• Migratie van een ITSM-procesautomatiseringssysteem van HP OpenView Service Desk naar OMNITRACKER CleverENGINE en optimalisatie van gebr(SK Alliance, 2014)
• Migratie van een ITSM-procesautomatiseringssysteem van HP OpenView Service Desk 4.5 naar OMNITRACKER CleverENGINE (KATREN, 2013)
• Migratie van een ITSM-procesautomatiseringssysteem van HP OpenView Service Desk 4.5 naar OMNITRACKER CleverENGINE (VTB24, 2012-2013)
• Migratie van het ITSM-procesautomatiseringssysteem (AutoSpetsTsentr, 2010)

Elk bedrijf streeft ernaar zo min mogelijk geld uit te geven, ook aan IT. Eén manier om geld te besparen is door informatiesystemen naar de cloud te verplaatsen. Bij het overbrengen van gegevens naar een gevirtualiseerde omgeving is het noodzakelijk rekening te houden met de wettelijke eisen rondom de opslag en verwerking van persoonsgegevens. Deze eisen gelden voor iedere organisatie.

Vladimir Lebedev, directeur bedrijfsontwikkeling bij Stack Group, vertelde ons over de fijne kneepjes van het migratieproces.

Wettelijke vereisten

In 2006 werd het aangenomen 152-FZ “Over persoonlijke gegevens”, die is ontworpen om individuen te beschermen tijdens de geautomatiseerde verwerking van persoonlijke gegevens. Vorig jaar is een pakket amendementen over de lokalisatie van persoonsgegevens op het grondgebied van Rusland van kracht geworden, die volgens de auteurs het niveau van informatiebeveiliging binnen de staat moeten verhogen en de Russische markt van technologische oplossingen en de informatievoorziening moeten stimuleren. veiligheidsmarkt.

Bedrijven zijn wettelijk verplicht om persoonsgegevens op het grondgebied van de Russische Federatie te verzamelen, op te slaan en te verwerken. Alle eisen zijn exact hetzelfde voor zowel Russische als buitenlandse bedrijven als hun activiteiten gericht zijn op Russisch grondgebied. Tegelijkertijd is het mogelijk om persoonlijke gegevens naar het buitenland over te dragen, maar deze moeten onveranderlijk zijn en het volume ervan mag het volume in Russische databases niet overschrijden.

Voor wie is de wet?

Elke organisatie treedt op als beheerder van persoonlijke gegevens, bijvoorbeeld haar werknemers, klanten en partners. Daarom vallen alle bedrijven in alle sectoren onder de wet. Potentiële inspecties vormen echter vooral een bedreiging voor bedrijven waarvan de commerciële activiteiten gebaseerd zijn op de verwerking van persoonsgegevens: banken, verzekeringsmaatschappijen, bedrijven die medische diensten verlenen en dergelijke.

Het inspectieplan van Roskomnadzor voor 2016 omvatte: de grootste softwarebedrijven, internationale banken, netwerkhandelsbedrijven en online winkels.

Moeilijkheden bij de overdracht van persoonlijke gegevens voor internationale bedrijven

Vaak zijn mondiale internationale spelers, om aan de wettelijke vereisten te voldoen, gedwongen om niet alleen de gegevens zelf, maar ook alle gerelateerde systemen naar Rusland over te dragen: bedrijven met gecentraliseerde IT-systemen vinden het uiterst moeilijk om de architectuur van het informatiesysteem te veranderen om voldoen aan één lokale wetgeving, omdat het aanvankelijk geen afzonderlijke informatieverwerkingscentra had. Het opnieuw opbouwen van informatiesystemen vergt aanzienlijke investeringen.

Virtualisatie

Overstappen naar de cloud is goedkoper dan het kopen en installeren van hardware. Eind 2014 waren de prijzen voor Russische wolken gemiddeld 15-30% hoger dan die voor Europese, en eind 2015 werden onze prijzen daarentegen 20-30% lager: de wisselkoers en de relatieve kosten van plaatsing in Russische data veranderd -centra.

Operators begonnen een volwassener product aan te bieden en buitenlandse bedrijven konden kiezen uit virtualisatiesystemen, prijssegmenten en er ontstonden kansen voor de connectiviteit van Russische en westerse infrastructuren.

Voor buitenlandse bedrijven is virtuele infrastructuur een betrouwbare en begrijpelijke oplossing. Veel bedrijven brengen informatie uitsluitend over naar een gevirtualiseerde omgeving, die ook de nodige middelen biedt om persoonlijke gegevens te beschermen. Bij een verhuizing verwachten buitenlandse bedrijven uiteraard dat de exploitant voldoet aan de wettelijke vereisten voor informatiebescherming.

Risico's die ontstaan ​​bij het migreren van gegevensopslagsystemen

De migratieprocessen zelf van het ene systeem naar het andere brengen risico's met zich mee. In de eerste plaats kan het vastgestelde niveau van klantenservice worden geschonden. De communicatie kan ook worden onderbroken en het werk van afdelingen waarvan de activiteiten verband houden met geautomatiseerde systemen kan worden opgeschort; er kunnen zich omstandigheden voordoen waarin het onmogelijk is om te voldoen aan de eisen op het gebied van informatiebeveiliging, en er kunnen andere technische problemen optreden. Daarom is het belangrijk dat aanbieders bereid zijn de bedrijfscontinuïteit te garanderen door gebruik te maken van betrouwbare en beproefde oplossingen voor het migreren van informatiesystemen.

Stadia van cloudmigratie

We zullen de algemene principes van servicemigratie bekijken, dat wil zeggen het overbrengen van de besturingssystemen die verantwoordelijk zijn voor de werking van deze service naar een gevirtualiseerde omgeving, waarbij we het voorbeeld van de oplossing gebruiken VMware vSphere.

Het is raadzaam om de architectuur van de informatiesystemen van een bedrijf op te delen in diensten die specifieke taken uitvoeren. Meestal wordt alles naar de cloud verplaatst, behalve diensten die om technische redenen niet compatibel zijn met cloudtechnologie (RISC-architectuur) en diensten die vanwege een licentie niet kunnen worden verplaatst.

Vervolgens heb je nodig audit van informatiesystemen. In dit stadium wordt de samenstelling van de diensten bepaald (welke besturingssystemen bij een bepaalde dienst horen), evenals hun connectiviteit. De grootste moeilijkheid ligt in de verscheidenheid aan bronbesturingssystemen en de fysieke architectuur van de servers waarop ze draaien. Op basis van deze informatie wordt een migratieplan opgesteld, waarbij rekening wordt gehouden met de huidige bedrijfsprocessen: eisen aan de connectiviteit van fysieke en virtuele infrastructuren, de migratievolgorde worden bepaald en aanvaardbare “migratievensters” worden vastgesteld. Het is belangrijk om te onthouden dat u tijdens de migratie geen versies van softwareproducten of besturingssystemen kunt bijwerken. Gelijktijdig met de migratie is alleen een herziening van computerbronnen (CPU, RAM, HDD) toegestaan.

In de regel wordt het hulpprogramma gebruikt voor migratie VMware-converter, dat effectief werkt bij het migreren van Microsoft Windows-besturingssystemen (maar het migreren van services die op deze besturingssystemen draaien, heeft zijn eigen nuances). Maar vanwege de eigenaardigheden van Linux-bestandssystemen start de virtuele machine in ongeveer 40% van de gevallen na het voltooien van de VMware-converter niet op. Als LVM op Linux wordt gebruikt, moet u een nieuw besturingssysteemexemplaar van de providersjabloon in een virtuele omgeving implementeren en vervolgens gegevens, softwareproducten en interne services overbrengen.

Voor elk type besturingssysteem zijn er algemene voorwaarden die migratie moeilijk maken: ten eerste is de methode voor het opslaan van gegevens, waardoor directe migratie onmogelijk is, dynamische schijven in Windows of LVM in Linux, en ten tweede problemen als gevolg van het gebruik van software- en hardware-RAID-arrays. Zelfs een nauwkeurige gegevensoverdracht garandeert dus op zichzelf niet dat de virtuele machine succesvol zal opstarten. Op een fysieke server wordt de werking van virtuele machines verzekerd door een hypervisor - een besturingssysteem dat de fysieke server verdeelt in verschillende virtuele machines die tegelijkertijd kunnen werken en dezelfde fysieke bronnen kunnen gebruiken. Uiteraard valt de set virtuele hardware in de hypervisor niet samen met de hardware van de fysieke server waarop het besturingssysteem vóór de migratie draaide. Vanwege het verschil in stuurprogramma's zijn er daarom veel verschillen in de toegang tot deze apparatuur.

Migratie van ADDS en MS SQL zonder services te stoppen

Bijna altijd moet een bedrijf tijdens de migratie een aantal diensten beschikbaar houden. Tegelijkertijd is dat vaak zo migratie zonder de service te stoppen aanbevolen als de meest betrouwbare. Daarom zullen we de kenmerken van migratie overwegen zonder de meest populaire Microsoft OS-services te stoppen: Active Directory Domain Services (ADDS of AD) en Microsoft SQL (MS SQL). Om Active Directory te migreren zonder de service te stoppen, wordt het volgende algoritme gebruikt:

• Er wordt netwerkconnectiviteit gevormd tussen de fysieke apparatuur en de gevirtualiseerde omgeving. Meestal is dit een site-to-site VPN; het creëert een logisch netwerk bovenop een ander netwerk. In dit geval kan het verkeer worden beschermd door versleuteling met behulp van IPsec-protocollen.
• In de cloud implementeren we nieuwe virtuele machines vanuit een template, waar we AD-domeincontrollers configureren en toevoegen aan het forest.
• We repliceren de Active Directory-database via VPN via het netwerk, van draaiende controllers aan de kant van de fysieke apparatuur tot aan de cloud-controllers.
• Na de gegevensreplicatie wijzen we de operationele rolmasters opnieuw toe aan cloudcontrollers en verwijderen we de domeincontrollerrollen van de servers.
• Vervolgens controleren we de werking van de diensten en schakelen we de accounts van de oude controllers en fysieke apparatuur uit.

Algoritme MS SQL-migraties complexer, omdat MS SQL meestal wordt gebruikt in een service met meerdere niveaus als backend. DNS-records in toepassingen die databases gebruiken (MS SQL-clients) moeten handmatig worden opgegeven op de nieuwe databaselocatie. Daarom kan downtime niet volledig worden geëlimineerd, maar wel worden geminimaliseerd. Er zijn mechanismen voor non-stop migratie van MS SQL, waaronder Spiegelen En Altijd aan, maar het gebruik ervan is niet altijd gerechtvaardigd. AlwaysOn is alleen beschikbaar in dure Enterprise-edities en Mirroring moet worden ondersteund door MS SQL-clients. Om de Mirroring-mechanismen te kunnen gebruiken, is bovendien aanvullende configuratie van alle MS SQL-clients vereist.
Laten we eens kijken naar de meest voorkomende optie voor het migreren van MS SQL naar de cloud:

• Netwerkconnectiviteit tussen de cloud en fysieke apparatuur is geconfigureerd.
• Wij zorgen ervoor dat het MS SQL-databaseherstelmodel compleet is, waarna u een volledige back-up kunt maken en overbrengen, en vervolgens beide databases kunt synchroniseren, waarbij kopieën van transactielogboeken worden overgedragen.
• In de cloud zetten we vanuit een template een virtuele machine in, waarin we een nieuwe MS SQL-server installeren en configureren.
• We maken een volledige back-up van de MS SQL-serverdatabase die op een fysieke server draait en herstellen deze vervolgens in de cloud, terwijl de methode voor het overbrengen van de back-upkopie afhangt van de bestandsgrootte en netwerkbandbreedte - we verplaatsen deze naar een fysiek medium of kopie het via het netwerk.
• Na het herstellen van de database in de cloud maken wij een kopie van de transactielogs en herstellen deze ook in de cloud.
• Tijdens de ‘migratieperiode’ stoppen we met het draaien van de MS SQL-server op fysieke hardware, maken en herstellen we de laatste minimale kopie van transactielogboeken in de cloud, starten we de MS SQL-server in de cloud en schakelen we clients over naar de nieuwe databaselocatie .
• We controleren de werking van services, schakelen fysieke apparatuur uit.

Voor elke dienst en dienst zijn er vele migratiemethoden, afhankelijk van de omstandigheden. Een serviceprovider helpt u problemen te voorkomen die zich tijdens de migratie kunnen voordoen.

Informatiebeveiliging

Bedrijven moeten niet alleen gegevens naar Rusland overbrengen, maar ook zorgen voor een passend niveau van informatiebeveiliging voor de opslag ervan.

In de lijst met documenten die de vereisten definiëren en de maatregelen beschrijven die nodig zijn om informatiesystemen te beschermen, is de eerste plaats uiteraard de wet zelf, die algemene vereisten vaststelt. Specifieke acties worden geregeld door decreten van de regering van de Russische Federatie en regelgevingsdocumenten van FSTEC (Federale Dienst voor Technische en Exportcontrole) en FSB (Federale Veiligheidsdienst).

Vereisten voor het opslaan van persoonlijke gegevens

De vereisten voor de technische bescherming van vertrouwelijke informatie en het aanbieden van informatiebeschermingsdiensten zijn vrij duidelijk geformuleerd. De instrumenten voor de implementatie ervan zijn divers. Dit kunnen met name firewalls, inbraakdetectiesystemen, beveiligingsanalysetools, antivirusbescherming en tools voor de bescherming van virtualisatieomgevingen zijn. De markt biedt een breed scala aan informatiebeveiligingstools van zowel Russische als buitenlandse leveranciers. Er bestaat al wetshandhavingspraktijk, aangezien de wet sinds 2007 van kracht is. In het algemeen verschilt de aanpak van regulering in Rusland van bijvoorbeeld de Europese aanpak. In Rusland leidt het niet naleven van voorgeschreven informatiebeveiligingseisen dus tot aansprakelijkheid. Maar in het Westen kan een bedrijf zelfstandig bepalen hoe aan eisen moet worden voldaan, en ontstaat er alleen aansprakelijkheid als er onrechtmatig wordt gehandeld met persoonsgegevens.

Infrastructuurvereisten

Toezichthouders stellen ook bepaalde eisen aan de infrastructuur. Dat is er bijvoorbeeld certificering van ingebouwde geautomatiseerde systemen die informatiebeveiliging garanderen. Het certificaat wordt afgegeven door een onafhankelijk laboratorium, wat bevestigt dat de infrastructuur gereed is en voldoet aan alle eisen voor de beveiliging van informatiesystemen. Dit certificaat is niet verplicht voor commerciële organisaties, maar maakt het wel mogelijk om te begrijpen dat het datacenter over de nodige bescherming beschikt en in staat is de veiligheid van bedrijfsgegevens te waarborgen.

Er zijn ook internationale ISO-normen die de constructie van een managementsysteem voor informatiebeveiliging reguleren ( set ISO 2700x-normen). Veel buitenlandse bedrijven voldoen aan deze normen.

Daarnaast wordt er gebruik gemaakt van een outsourcingmodel voor gegevensbescherming. Bedrijven die dergelijke diensten verlenen, moeten over de nodige vergunningen en competenties beschikken.

INFO

Prognose voor overdracht

Het is vrij lastig om precies te berekenen hoeveel data er naar Rusland moet worden overgedragen, maar op basis van de bezetting van de datacentermarkt kunnen we stellen dat de capaciteit ruim voldoende is om data conform de wet te lokaliseren. Op de markt van de regio Moskou is er bijvoorbeeld een overaanbod aan capaciteit: de totale capaciteit is ongeveer 27 duizend rekken, en bijna 40% daarvan is gratis. Veel datacenters hebben gebieden met een hoge beschikbaarheid. Houd er ook rekening mee dat de datadichtheid in één rack kan variëren, afhankelijk van de apparatuur. Tegenwoordig verwerkt één serverrackunit aanzienlijk meer informatie dan een paar jaar geleden.

Tegelijkertijd is de vraag ongelijkmatig: een jaar geleden was er sprake van een vrij forse stijging, nu is het aantal verzoeken van buitenlandse bedrijven afgenomen. Sommige bedrijven zijn al verhuisd en voldoen aan de eisen, terwijl andere bijvoorbeeld wachten op de resultaten van controles van de regelgeving (deze zullen de vorming van de tweede golf beïnvloeden).

Er is veel veranderd in de wereld van de informatietechnologie in de afgelopen 32 jaar sinds Microsoft Windows 1.0 uitbracht. Het enige dat hetzelfde blijft, is de complexiteit van het migratieproces, oftewel de transitie naar een nieuwe versie van het besturingssysteem, en de implementatie van updates. Als u gebruikers vraagt ​​wat ze van een migratie verwachten, is het antwoord dat u krijgt een soepele overgang met minimale downtime en een vertrouwde desktopervaring. Sommigen zullen zeggen dat ze tegen migratie in het algemeen zijn, maar dit zijn er meestal maar weinig.

Waarom migratie nodig is

Er zijn veel redenen om desktopmigratie te bevorderen. De twee belangrijkste zijn veiligheid en exploitatiekosten. Microsoft-ontwikkelaars hebben de beveiliging van desktopbesturingssystemen gestaag verbeterd; De lijst met beveiligingstechnologieën die in oudere versies niet aanwezig waren, is indrukwekkend. De bedreigingen worden steeds geavanceerder en Microsoft heeft functies moeten toevoegen, zoals het lanceren van de ELAM anti-malware-oplossing tijdens de eerste fase van het opstarten (https://docs.microsoft.com/en-us/windows-hardware/drivers/ install/early-launch-antimalware ) en gecontroleerde maptoegang (https://docs.microsoft.com/en-us/windows/threat-protection/windows-defender-exploit-guard/controleerbare-folders-exploit-guard), een uitstekende manier om je te beschermen tegen malware, is op zichzelf al voldoende reden om na te denken over migratie. Beveiliging is een bijzonder ernstig probleem voor bedrijven die nog steeds versies van het besturingssysteem Windows 7 (en zelfs Windows XP) gebruiken, omdat de bedreigingen sindsdien aanzienlijk zijn veranderd en de verbeteringen die in Windows 10 zijn aangebracht in sommige opzichten de meest fundamentele en niet altijd voldoende zijn. beveiligings niveau.

Bedrijfskosten zijn een andere belangrijke factor; Migratie is vaak gekoppeld aan de updatecycli van hardware en Microsoft Office-suites, waardoor steeds meer bedrijven virtualisatie overwegen om hun afhankelijkheid van updates van hardware en desktopbesturingssystemen te doorbreken. Zelfs bedrijven die fysieke hardware willen behouden, kunnen profiteren van de potentiële besparingen als ze een huidige generatie versie van Windows op moderne hardware draaien.

Migratie proces

De onderstaande figuur toont een eenvoudig diagram van de belangrijkste stappen in het migratieproces.

Er zijn veel verschillende benaderingen voor het uitvoeren van elke fase; Er zijn hele boeken geschreven over het uitvoeren van bijvoorbeeld pilot-IT-projecten. Laten we elke fase kort bekijken vanuit het perspectief van migratie.

Milieu-inventaris

Veel bedrijven beschikken over geavanceerde inventaris- en beheersystemen die vragen kunnen beantwoorden als “op hoeveel actief gebruikte desktops draait Windows 8.1 SP2?” of “hoeveel Dell XPS 13-laptops zijn er op voorraad?” Voor de inventarisatie kunnen beheersystemen zoals System Center Configuration Manager (SCCM) en Microsoft Intune worden gebruikt als u over voldoende tools beschikt en deze heeft ingezet. Anders moet u mogelijk uw toevlucht nemen tot minder efficiënte methoden, zoals het vragen om feedback van gebruikers, het voorbereiden van een inventarisatietool en het promoten ervan via Groepsbeleid, of het handmatig inventariseren en configureren van systeeminstellingen. De belangrijkste voorwaarde in dit stadium is het verkrijgen van een accuraat model van bestaande systemen om de gewenste staat correct te plannen.

Gewenst staatsontwerp

De term ‘gewenst staatsontwerp’ verwijst naar de zoektocht naar de vorm die wij willen dat onze omgeving in de toekomst aanneemt. Bovendien wordt er in deze fase gewerkt aan een langetermijnplan om uw intenties te realiseren. Het plan om de gewenste migratiestatus te bereiken moet de volgende informatie bevatten.

• Wat neem je over van het uitgangspunt (milieu-inventarisatie vereist).
• Wat neem je mee naar je bestemming? Er zijn talloze vragen die moeten worden beantwoord, waaronder: Naar welke versie van Windows upgradet u? Blijft u op fysieke desktops, verhuist u naar een virtuele omgeving op locatie of verhuist u naar de cloud? Hoe wordt de doelomgeving geconfigureerd? Wat moet ik doen als de migratie mislukt of systemen niet kunnen worden gemigreerd?
• Jouw schema. De meeste bedrijven moeten over een langere periode migreren, in plaats van in één grote sprong. Wanneer moeten bepaalde gebruikers worden overgedragen? Hoe ziet het rooster er in het algemeen uit en hoe weerspiegelt het externe gebeurtenissen (zoals het begin van het schooljaar, het einde van het fiscale jaar of het verkoopseizoen)?
• Jouw zaken. Migreert u om specifieke doelen te bereiken? Er kunnen bedrijfsapplicaties zijn die moeten worden gemigreerd, of er kunnen speciale wettelijke of nalevingsvereisten zijn voor de nieuwe omgeving.

Het doel van deze fase is om u te helpen begrijpen wat de mogelijkheden van de voltooide omgeving zouden moeten zijn en hoe u van uw huidige situatie kunt komen naar waar u wilt zijn. Het is onmogelijk om hier te veel tijd aan te besteden of te veel aandacht aan details te besteden. Het oude spreekwoord – twee keer meten, één keer knippen – is de beste leidraad voor actie. In dit stadium hoeft u doorgaans geen wijzigingen in de omgeving aan te brengen.

Laten we beginnen met het maken van een prototype

U begint nu met het bouwen van de omgeving die is beschreven in de vereiste staatsontwerpfase. Stel je voor dat je een huis bouwt: je begint op een leeg stuk grond, verwijdert de grond, stort beton voor de fundering en begint met het bouwen van de muren. Er is een bepaalde minimale hoeveelheid werk die moet worden voltooid om een ​​woning te kunnen betrekken, maar u kunt ook in een onafgewerkt huis wonen. Voor migratie geldt hetzelfde: voordat een pilotproject wordt uitgevoerd, moet minimaal een deel van de nieuwe omgeving worden ontworpen, gebouwd en getest. Voor interne VDI-implementaties is bijvoorbeeld een hypervisoromgeving van de juiste omvang nodig, waarbij de benodigde licenties moeten worden verkregen, enz., voordat een enkele desktop kan worden getest. Maar het is niet nodig om de volledige vereiste staatsomgeving volledig te bouwen. Deze fase is vaak gepland om de inzet van verschillende componenten af ​​te stemmen op de daadwerkelijke migratie.

Een van de voordelen van de bouwfase is de gemakkelijke mogelijkheid om extra veiligheidsmaatregelen in de planning in te bouwen. Het punt is dat, afhankelijk van de aard van de migratie, een klein aantal gebruikers in een pilotproject doorgaans al in het begin naar het nieuwe platform kan worden gemigreerd. Hierdoor kunt u uw omgeving proactief monitoren en eventuele problemen oplossen, en experimenteren met tools en instellingen voordat iedereen in de pilot deze krijgt.

Bovendien is de bouwfase van het prototype een goed moment om tekortkomingen in de bestaande omgeving aan te pakken die vóór de implementatie moeten worden aangepakt.

Proeffase

Bij het ontwerpen van een nieuw vliegtuig of nieuwe raket plannen ingenieurs een uitgebreid testvluchtprogramma. Elke testvlucht heeft een specifiek doel, dat eenvoudig kan zijn (het uitschuiven van het landingsgestel testen en op verschillende snelheden omhoog brengen) of complex (het manoeuvreren van 2v2-jagers). Testpiloten improviseren niet tijdens vluchten; ze volgen strikt de instructies voor elke vlucht en bereiken hun doelen. Uw pilot zou op dezelfde manier moeten werken: specificeer wat bewezen, getest of geverifieerd moet worden, en zorg er vervolgens voor dat alle activiteiten in de pilot gericht zijn op het bereiken van het gestelde doel. Te vaak betekent een pilotprogramma eigenlijk 'kies een paar willekeurige gebruikers en kijk wat er misgaat'. Een goed pilotprogramma begint met het gestructureerd testen van een reeks basisfunctionaliteiten: het migreren van een enkele gebruiker, het migreren van een groep gebruikers, het testen van de resulterende omgeving met alledaagse taken, en dan overgaan naar complexere scenario's. Gestructureerd testen is vooral belangrijk als u van een traditionele desktopomgeving naar de cloud of virtuele elementen overstapt. Het zal tijd kosten om te leren hoe u de cloudomgeving of hypervisor moet beheren, inclusief het verkrijgen van leveranciersondersteuning in geval van problemen tijdens de pilotfase.

Hoewel deze activiteit niet als een aparte stap wordt beschouwd, is dit wel het beste moment om gebruikers kennis te laten maken met de nieuwe omgeving. Het zou geweldig zijn als je een nieuwe desktopomgeving zou kunnen uitrollen zonder gebruikers te trainen, maar de realiteit is dat je de tijd moet nemen om gebruikers vertrouwd te maken met de functies van de omgeving. Met een stabiel pilotprogramma kun je demonstraties geven, trainingsvideo's opnemen of gebruikers tijdens het leren een sandbox bieden met beperkte toegang tot een nieuwe omgeving. Vergeet niet dat ondersteuningstechnici waarschijnlijk ook training nodig hebben. Het is mogelijk dat er extra personeel nodig zal zijn om de toegenomen stroom aan serviceverzoeken aan te kunnen: “Ik kan functie X niet vinden” is een veelgehoorde klacht in de vroege stadia van de migratie.

Inzet

Tijdens de volledige implementatiefase vinden er grote gebeurtenissen plaats. Deze migratiefase verschilt niet veel van elk ander complex technisch project: u definieert een schema voor de migratie van verschillende groepen gebruikers en volgt vervolgens de geplande stappen, waarbij u problemen oplost zodra deze zich voordoen. Als de prototype- en pilotfase correct worden uitgevoerd, zouden er geen grote nieuwe problemen moeten optreden. Over het algemeen is het het beste om voorzichtig te zijn bij het ontwerpen van deze fase; Als u van plan bent 100 desktops per week te migreren en er uiteindelijk 150 te migreren, is dat beter dan 150 te plannen en 100 te doen. Vergeet vakanties, vakanties en andere personeelsbeperkingen niet. Voor een succesvolle implementatie moet u zich ervan bewust zijn dat u een omgeving migreert waarvan uw gebruikers afhankelijk zijn. U moet dit dus doen op een manier die de overlast voor hen tot een minimum beperkt.

Tegen de tijd dat de productierelease begint, moet het ondersteuningsteam over voldoende personeel beschikken, getraind zijn en klaar zijn om het aantal gebruikers dat wekelijks wordt gemigreerd aan te kunnen; uw nieuwe omgeving moet stabiel en goed presterend zijn, en pilotgebruikers moeten naadloos in de nieuwe omgeving kunnen werken. Als aan een van deze voorwaarden niet wordt voldaan, moet dit als waarschuwing dienen: stop en los de problemen op voordat u overgaat tot een volledige migratie.

Exploitatie

De operationele fase is een beetje saai omdat je daardoor wordt gedwongen terug te gaan naar waar je begon: de normale ondersteunende en beheeractiviteiten in een stabiele omgeving. Deze fase omvat het dagelijkse onderhoud van de nieuwe omgeving, inclusief het oplossen van problemen die gebruikers tegenkomen, het testen en het toepassen van regelmatige beveiligingsupdates van de leverancier. De pilotfase is als een toegangsweg tot het migratieproces, en deze fase is een snelweg; je zult er geen probleem mee hebben om met een constante snelheid te bewegen (tenminste tot de volgende grote update van Microsoft).

Vereenvoudig het proces

De juiste gereedschapskeuze zal de pilotfase en de introductie in productie aanzienlijk vereenvoudigen. Gebruikers moeten de ervaring kunnen ervaren met minimale verstoring, en de beste manier om aan deze behoefte te voldoen is door een doordacht ontwerp, profielmigratie en beheerde bedrijfsbrede oplossingen. Liquidware biedt bijvoorbeeld een Workspace Environment Management-pakket waarmee u elke stap van een Windows-migratie kunt voltooien, inclusief beoordeling en ontwerp met behulp van Stratusphere, en migratie met behulp van ProfileUnity User Management. Stratusphere ontdekt geïnstalleerde en gebruikte applicaties en helpt u bij het evalueren en voorbereiden van uw hardware voor Windows 10. Met ProfileUnity kunt u gebruikersprofielen naadloos migreren tussen elke versie van Windows en de migratie-inspanningen aanzienlijk verminderen. Met de Profile Bridge-technologie die in ProfileUnity wordt gebruikt, kunt u gebruikersprofielen in containers plaatsen en er naadloos mee werken in verschillende versies van Windows, zowel achterwaarts als voorwaarts compatibel. De functionaliteit van ProfileUnity vermindert de bewegings- en synchronisatietijd, en u kunt deze implementeren op desktops, laptops, virtuele systemen en cloudsystemen om gebruikers tegelijkertijd op alle apparaten een vertrouwde ervaring te bieden.

De meeste moderne bedrijven gebruiken verschillende informatieoplossingen bij hun activiteiten, en voor bijna elk bedrijf worden vroeg of laat kwesties met betrekking tot de integratie van informatiesystemen en/of migratie naar meer technologische platforms relevant. Er zijn vaak geen kant-en-klare antwoorden op deze vragen, daarom hanteert IDelync een alomvattende en evenwichtige benadering bij het kiezen van de optimale oplossingsopties voor elk bedrijf.

Door de integratie van verschillende informatieoplossingen kan het bedrijf:

werk organiseren met alle niveaus van bedrijfsgegevens, ongeacht het type softwareproducten;

het elimineren of minimaliseren van dubbele invoer van informatie in de bestaande informatieoplossingen van het bedrijf;

het organiseren van een uniforme informatieruimte van het bedrijf, met duidelijk gedefinieerde informatiestromen tussen verschillende oplossingen, afbakening van rechten tussen gebruikers.

Het belangrijkste voordeel van integratieoplossingen is dat het bedrijf in een kortere tijd en tegen lagere kosten een positief effect kan behalen uit het gebruik ervan dan bij het kiezen van oplossingen waarbij informatieoplossingen moeten worden vervangen of geüpgraded. De specialisten van IDelync hebben ruime ervaring met integratie en hebben projecten uitgevoerd van diverse informatiesystemen, zoals: 1C 7.7 --> 1C 8.x; Info accountant --> 1C; Turboaccountant --> 1C; Zeil --> 1C; WinkelHuis --> 1C; R-Keeper --> 1C; Excel --> 1C.

Migratie van systemen naar technologisch geavanceerdere platforms of oplossingen vindt plaats wanneer individuele informatieoplossingen verouderd zijn en niet langer voldoen aan de eisen van het bedrijf. Tegelijkertijd moet het bedrijf de transitie snel en efficiënt uitvoeren. Juist in deze – hoogwaardige en tijdsoptimale oplossingen – is IDelync gespecialiseerd. Daarnaast heeft ons bedrijf een uniforme geïntegreerde module ontwikkeld voor boekhoudsystemen gebaseerd op 1C:Enterprise, namelijk van 1C:Enterprise 7.7 naar 1C:Enterprise 8. Als gevolg van de migratie krijgt het bedrijf niet alleen een modernere, productievere oplossing, maar kan ook processen automatiseren die voorheen niet aan bod kwamen.

IDelync biedt aan om gefaseerd naar andere softwareproducten te migreren, waarbij de volgende fasen worden doorlopen:

Architecturale, analytische en bedrijfsaudit van bestaande IT-systemen. Dit werk wordt uitgevoerd om de huidige status van systemen te bepalen en informatie te verkrijgen voor het selecteren van een nieuw systeem. In dezelfde periode worden de businessvereisten voor de nieuwe oplossing verzameld, waardoor het mogelijk wordt om de benodigde modules in de nieuwe oplossing aan te bieden.

Technologieën selecteren voor het migreren van IT-systemen. In dit stadium wordt de selectie en het ontwerp van technologieën voor het uitvoeren van migratiewerkzaamheden uitgevoerd. Als er een migratie gepland is van verschillende configuraties van 1C:Enterprise 7.7 naar 1C:Enterprise 8, gebruikt IDelync een eigen module, die op veel projecten is getest.

Ontwikkeling en configuratie van het migratiemechanisme en het testen ervan.

Migratie naar een nieuwe oplossing, proefdraaien van het resulterende IT-systeem.

Inbedrijfstelling van IT-systemen, systeemondersteuning. Een zorgvuldige planning van de werkzaamheden met betrekking tot de inbedrijfstelling van een nieuw systeem maakt het mogelijk om op tijd een nieuwe oplossing te lanceren en minimaliseert de risico's die gepaard gaan met de implementatie van een nieuwe oplossing.

Systeemondersteuning wordt verleend op grond van een afzonderlijke overeenkomst met de Klant of de eigen IT-dienst van de Klant.

Dankzij het zorgvuldig verzamelen en analyseren van de zakelijke vereisten van de klant, het ontwerpen en testen van systeemintegratie- en migratiemechanismen en de duidelijke interactie met de klant in alle fasen van het werk, voert IDelync met succes de integratie en migratie van systemen uit, zowel binnen individuele projecten. en als onderdeel van complexe operationele automatiseringsprojecten, management accounting van bedrijven.

Meer diensten (3)

Meer oplossingen (1)

Meer ervaring (3)

• "ID.Integration": geïntegreerde gegevensuitwisselingsmodule

  Veel ondernemingen hebben inmiddels een hoge mate van automatisering bereikt. In de meeste gevallen beschikken bedrijven niet over één enkele informatieoplossing, maar over een reeks verschillende systemen die worden gebruikt voor lokale boekhoudtaken, zoals het bijhouden van boekhoudkundige en belastinggegevens, operationele en managementboekhouding, en het verkrijgen van de noodzakelijke rapportage.

  Het typische product op basis waarvan informatieoplossingen voor binnenlandse ondernemingen worden gemaakt, is 1C. In dit verband kunnen we de vragen benadrukken die het vaakst rijzen bij de ondernemingen van het bedrijf:

  Integratie– de noodzaak om verschillende afzonderlijke systemen te combineren om één enkele informatieoplossing te verkrijgen en de noodzaak weg te nemen om herhaaldelijk gegevens in afzonderlijke informatiedatabases in te voeren;

  Migratie– implementatie van een snelle en hoogwaardige transitie van oplossingen van elke versie van het boekhoudsysteem naar systemen van versie 1C:Enterprise 8.
  

  Om deze problemen op te lossen hebben de specialisten van IDelync een universele, geïntegreerde module ontwikkeld voor gegevensuitwisseling tussen verschillende boekhoudprogramma's en configuraties van 1C:Enterprise platforms versie 7.7 en 8.1.

  De geïntegreerde module biedt uitgebreide flexibele configuratiemogelijkheden:

  Synchronisatie van masterdata-objecten, inclusief de mogelijkheid om verschillende objecten uit een bron te combineren in één ontvangerobject om geaggregeerde gegevens te verkrijgen, evenals het vergelijken van objecten uit verschillende brondatabases met een enkele waarde in de ontvanger.

  Synchronisatie van PS, berichten en correspondentie - om zakelijke transacties weer te geven.

  Met behulp van een universele gegevensuitwisselingsmodule kunt u de volgende problemen correct oplossen:
  

  Gegevens uit meerdere boekhouddatabases samenvoegen tot één geconsolideerd systeem.

  Transformatie van boekhoudkundige boekingen zowel in boekhoudkundige boekingen van andere typen (Belasting, Internationaal, etc.), als in boekhoudkundige boekingen met andere correspondentie, afhankelijk van de analyseobjecten.

  Volledige automatisering van het gegevensuitwisselingsproces. In overeenstemming met de voorlopige opzet van de stamgegevens, PS en corrwordt een geautomatiseerd gegevensuitwisselingsproces uitgevoerd, waarna het voldoende is om eenvoudigweg de juistheid van de geladen gegevens te controleren.

  Mogelijkheid tot handmatige gegevensuitwisseling met flexibele voorlopige configuratie tot een afzonderlijke bewerking voor het weerspiegelen van de boekhouding van economische activiteiten. Tegelijkertijd is het aan de kant van de ontvangende basis mogelijk om de boekingen van geladen transacties handmatig aan te passen, op voorwaarde dat wijzigingen beschermd zijn tegen aanpassing wanneer de gegevens voor deze bewerking herhaaldelijk worden bijgewerkt.

  Opgemerkt moet worden dat het gebruik van de integratiemodule bij het migreren van een onderneming van systemen gebaseerd op 1C 7.7 naar 1C 8.1 het niet alleen mogelijk maakt om efficiënt en snel een “deel” van saldi over te dragen (d.w.z. saldi op boekhoudkundige rekeningen vanaf een bepaalde datum) , maar ook om een ​​volledige overdrachtsomzet op rekeningen te garanderen voor elke periode van gegevens die beschikbaar zijn in het huidige boekhoudsysteem. Deze aanpak maakt een overgang mogelijk van het ene boekhoudsysteem naar het andere, terwijl de mogelijkheid behouden blijft om gereguleerde rapportage te genereren voor de gehele rapportageperiode, ongeacht de startdatum van de inwerkingtreding van het nieuwe systeem.

Groot- en detailhandel, e-commerce

• Automatisering van managementboekhouding en optimalisatie van het bedrijfsproces van verkoop en logistiek voor LLC "Trading House "Slobozhanka"

  Het bedrijf "Trading House "Slobozhanka" LLC (hierna "TDS", "Enterprise" genoemd) is een importeur en distributeur van bekende merken cosmetica, hygiëneproducten en huishoudelijke artikelen. Met behulp van een ontwikkelde structuur verkoopt TDS aan zijn klanten een brede selectie cosmetische en hygiëneproducten van bekende merken van fabrikanten in Polen, Rusland, Oekraïne en China.

  De doelstellingen van dit project waren om door middel van automatisering de efficiëntie van de operationele en managementprocessen van de onderneming te vergroten op het gebied van boekhoudfuncties, management- en controlefuncties.

  Rekening houdend met de continue werking van de Enterprise, evenals met tamelijk complexe logistieke problemen die verband houden met de behoefte aan een snelle, hoogwaardige organisatie van transportladingen, was de belangrijkste taak die moest worden opgelost in termen van operationele boekhouding de optimalisatie van orderverwerkingsprocessen. , voorbereiding van documenten die nodig zijn voor verzending, laden van voertuigen en hun verzending.

  Op basis van de resultaten van een voorlopig onderzoek, gebaseerd op een analyse van de zakelijke vereisten van de onderneming, adviseerde de consultant een overgang van het Granit-informatiesysteem naar een ERP-klassesysteem gebaseerd op 1C Enterprise 8. De 1C “Manufacturing Enterprise Management”-configuratie werd gekozen als basisoplossing. Een uniform operationeel en managementboekhoudsysteem implementeert een bedrijfsproces voor het beheren van de afhandeling van klantorders, dat de taken omvat van documentvoorbereiding, transport- en magazijnlogistiek en controle van de verzendingsbevestiging. Om het proces van het ontvangen van klantorders te optimaliseren, implementeert het systeem een ​​breed scala aan integratiemogelijkheden met externe bronnen (Emigo, Exite, EXCEL, PDA). Het systeem implementeert ook een prijsproces per merk en klant, evenals een mechanisme voor het monitoren van vorderingen per merk en looptijd. De geïmplementeerde oplossing bestrijkt alle blokken van de economische activiteit van de onderneming en stelt u ook in staat de boekhouding van vaste activa bij te houden, de managementloonadministratie te berekenen, klantrelaties (CRM) te beheren en financiële overzichten te ontvangen voor elke renteperiode (ook op dagelijkse basis). In het financiële rapportageblok zijn de volgende rapportages geïmplementeerd: Overzicht financiële resultaten, Kasstroomoverzicht, Balans. Het uniforme managementboekhoudsysteem is geïntegreerd met boekhoudsystemen voor de daaropvolgende voorbereiding van gereguleerde rapportage, en er is integratie met het Client-Bank-systeem uitgevoerd.

• Technosila, innovatie en re-engineering voor e-commerce, fusie van Technosila met de Technoshok-groep

  Tehnosila, Moskou, Rusland, http://www.tehnosila.ru, een van de leiders in winkelketens op het gebied van de handel in elektronica en huishoudelijke apparaten in Rusland. 50 regio's, 137 winkels en een online winkel voor alle regio's.

  Projecten: IT Audit van informatiesystemen en bedrijfsomgeving (SAP, 1C, PHP, FoxPro, Delphi); Beheer van IT-projecten en bedrijfsinnovaties voor e-commerce; Herontwerp van bedrijfsprocessen voor e-commerce; IT-architectuurontwerp voor e-commerce, integratie en online interactie; Implementatie van IT-projecten voor e-commerce; Fusie van Technosila met de Technoshok-groep, http://tshok.ru, St. Petersburg, Rusland, 16 steden, 42 winkels en een online winkel.

• • Integratie van MS CRM (Microsoft Dynamics 4.0) en 1C.8.1 "Manufacturing Enterprise Management" voor een groep internetbedrijven SUP en +SOL, Moskou, Rusland

    Het doel van dit project was de ontwikkeling en implementatie van een applicatie die het probleem oplost van het uitwisselen van informatie in een vastgesteld formaat tussen het gespecialiseerde informatiesysteem Microsoft Dynamics CRM 4.0 en het managementsysteem gebaseerd op 1C: 8.1 “Manufacturing Enterprise Management”.

    Het geïmplementeerde mechanisme voert tweerichtingsuitwisseling van informatie uit tussen informatiebases in een onlinemodus. Als resultaat van elke gegevensuitwisselingssessie ontvangt de UIS bijgewerkte regelgevings- en referentie-informatie over klanten, productitems, klantverzoeken, en in de tegenovergestelde richting (in vergelijking met MS CRM) wordt informatie over betalingen en documenten die voor de klant zijn uitgegeven, verzonden.

    Het ontwerp en de implementatie van het gegevensuitwisselingsmechanisme werden uitgevoerd door de consultant in nauwe samenwerking met een externe implementator van een informatiesysteem voor klantrelatiebeheer (CRM) op basis van het Microsoft Dynamics CRM 4.0-product. Een duidelijke organisatie van het werk op het gebied van de interactie met een extern ontwikkelteam maakte het mogelijk om in korte tijd een mechanisme voor gegevensuitwisseling te ontwerpen, implementeren en implementeren en het bedrijf van de nodige, consistente informatie in beide systemen te voorzien.

In dit artikel willen we onze ervaring met het uitvoeren van datamigratie in grote bedrijfsprojecten met betrekking tot de transitie van klanten naar het werken in 1C:Enterprise 8-configuraties systematiseren.

Tegelijkertijd zal de nadruk in het artikel allereerst liggen op de technologische component van het migratieproces. Ook de organisatorische component wordt beïnvloed, maar in mindere mate.

Termen en definities

Datamigratie wordt doorgaans opgevat als een laatste reeks werkzaamheden, een project gericht op een eenmalige massale verplaatsing van gegevens van bronsystemen (historische systemen) naar het bestemmingssysteem. Tegelijkertijd stopt de exploitatie van deze gegevens in de bronsystemen.

Datamigratie moet onderscheiden worden van data-integratie. Integratie is, in tegenstelling tot migratie, een permanent onderdeel van de IT-architectuur en is verantwoordelijk voor de gegevensstroom tussen verschillende systemen en datastores - en is eerder een proces dan een projectactiviteit.

Het migratieschema ziet er in het algemeen als volgt uit:

Rijst. 1

Historische systemen- databases van het bedrijf van de Klant, die naar verwachting geheel of gedeeltelijk zullen worden vervangen bij de implementatie van een nieuw systeem.

Ontvanger systeem- doelsysteem, willekeurige configuratie “1C:Enterprise 8”.

Initiële data- gegevens gedownload van historische systemen naar een aangepast xls-bestandsformaat. In dit geval lijkt het xls-formaat een van de handigste, aangezien de mogelijkheid om naar een xls-bestand te uploaden aanwezig is in veel boekhoudsystemen van “vorige generaties”.

Als modern alternatief is het mogelijk om het xml-bestandsformaat als transport te beschouwen.

Er zijn ook mogelijkheden voor het gebruik van een tussendatabase.

Transformatie, conversie- het proces van het omzetten van brongegevens in te laden gegevens. Gegevenstransformatie vindt plaats in overeenstemming met het laden van sjablonen. Het resultaat van de transformatie zijn de gegevens die moeten worden geladen.

Gegevens om te downloaden- gegevens bedoeld om in het ontvangende systeem te worden geladen. In dit artikel wordt, evenals in de brongegevens, rekening gehouden met het xls-formaat.

Gegevenssjablonen voor laden- beschrijving van gegevenstabellen die in het doelsysteem moeten worden geladen.

Migratiefasen

Laten we het proces van het voorbereiden en uitvoeren van de migratie eens stap voor stap bekijken.

De organisatorische fasen van migratie omvatten de volgende punten:

· Het definiëren van een migratiestrategie. In dit stadium komen de Opdrachtnemer en de Klant tot overeenstemming over de technologie voor het uitvoeren van de migratiewerkzaamheden;

· Bepaling van de samenstelling van de migratiewerkgroep. In de werkgroep dienen specialisten van zowel opdrachtnemer als opdrachtgever te zitten die voldoende bekend zijn met de werking van historische systemen (aan de kant van de klant) en het doelsysteem (aan de kant van de opdrachtnemer);

· Voorlopig migratieplan. Het migratieplan zal naarmate het project vordert meerdere malen worden aangepast;

· Dataperioden voor het downloaden van gegevens uit historische systemen, gegevensvolumes. Gegevensafsluitingsperioden voor migraties, data van test- en definitieve migraties. Deze informatie kan worden toegeschreven aan het migratieplan;

· Samenstelling van de te migreren gegevens. Referentiegegevens, classificatoren, transactiegegevens, saldi, omzet, etc.;

· Kwesties van het controleren van de kwaliteit, juistheid en integriteit van gegevens tijdens het migratieproces en aan het eind;

· Problemen met het terugdraaien naar een vorige status in geval van storingen.

Laten we de technologische stadia van migratie eens nader bekijken.

Rijst. 2

1. Sjablonen voor het laden van gegevens voorbereiden

Het gegevenslaadsjabloon bevat technische beschrijvingen van de gegevenstabellen die moeten worden geladen, algoritmen en laadregels voor het huidige sjabloon.

Elke sjabloon richt zich doorgaans op een of meer gerelateerde tabellen op het doeldoelsysteem.

In het sjabloon staat:

· Beschrijving van alle velden van het xls-gegevensbestand om te downloaden, inclusief:

o Veldnaam

o Indicator dat het veld moet worden ingevuld

o Voorbeeld van het invullen van het veld

o Opmerking

· Beschrijving van de regels voor het laden van de doelsysteemtabel op basis van de te laden gegevens (wachtrij bij meerdere gerelateerde tabellen, zoekalgoritmen voor sleutelvelden, enz.)

· Beschrijving van het rechtstreeks invullen van de velden van de doelsysteemtabellen als er iets anders is dan het “één op één” overbrengen van gegevens uit een gegevensbestand om te laden. Relevant voor bijvoorbeeld referentievelden.

Tijdens de werkzaamheden in deze fase moet de contractant ook een laadprogramma voor gegevensbestanden gereedmaken voor het laden. Bij het werken met xls-bestanden is deze taak niet bijzonder moeilijk.

2. Identificatie van gegevensbronnen

Deze fase kan samen met de vorige fase “1” beginnen. Sjablonen voor het laden van gegevens voorbereiden."

In dit stadium bepalen de specialisten van de Klant uit welke systemen en welke gegevens gedownload kunnen worden. U moet ook bepalen welke gegevens Misschien kan nodig zijn.

Bij grote migratieprojecten kan het identificeren van een volledige, uitputtende lijst met gegevensbronnen in de regel behoorlijk veel tijd in beslag nemen en dit gebeurt naarmate het werk in de volgende fasen wordt voortgezet.

Er zijn vaak situaties waarin, om de integriteit van de informatie verder te garanderen, bepaalde gegevens moeten worden overgebracht uit gedrukte bronnen (gedigitaliseerd) of zelfs in tabellen moeten worden ingevoerd volgens de woorden van de belangrijkste medewerkers van de Klant.

In dit stadium moet u echter proberen zoveel mogelijk noodzakelijke gegevens te identificeren.

3. Brongegevens uploaden

Het proces van het downloaden van gegevens uit historische systemen kan behoorlijk wat tijd in beslag nemen, vooral als er veel systemen zijn, deze verschillend zijn en verschillende afdelingen van de Klant er verantwoordelijk voor zijn. Met dit punt moet rekening worden gehouden tijdens test- en eindmigraties.

De handigste optie lijkt het uploaden naar xls-bestanden te zijn. Veel oudere IT-systemen ondersteunen deze optie.

Er kunnen ook opties zijn voor het uploaden naar csv-formaat, dbf, xml-formaten en andere.

Het is vermeldenswaard dat de Klant om de een of andere reden (bijvoorbeeld veiligheidsproblemen) in dit stadium niet altijd de volledige gegevensdownloads kan leveren! Alleen een datastructuur en een paar testposities. Er kan zich dus een situatie voordoen dat tijdens test- en eindbelastingen gegevens van lage kwaliteit in de brontabellen worden gedetecteerd, wat tot ongeplande fouten zal leiden.

Om dit probleem tot een minimum te beperken, moet vooraf overeenstemming worden bereikt over het aantal testdownloads van historische systemen.

4. Gegevens in kaart brengen

Mapping (data mapping) - in het algemeen het proces van het vergelijken van gegevens uit historische systemen en het ontvangende systeem. Dat wil zeggen, de brongegevens en de gegevens die moeten worden geladen.

De fase van het in kaart brengen is de meest arbeidsintensieve fase en kan meer dan 50% van al het werk aan de migratietaak in beslag nemen.

In dit stadium is de gehele werkgroep van het migratieproject er volledig bij betrokken.

Bij het in kaart brengen van gegevens is het noodzakelijk om onderscheid te maken tussen de subfasen van het in kaart brengen van tabellen en het in kaart brengen van velden.

· In kaart brengen van tabellen, of in kaart brengen van sjablonen - vergelijking van tabellen met brongegevens en gegevenssjablonen voor laden. De match kan 1:1 of N:N zijn. Als resultaat van dit werk wordt een register voor tabeltoewijzingen samengesteld en onderhouden. Deze subfase is noodzakelijk voor de volgende subfase van het in kaart brengen van velden en voor het monitoren van de algemene stand van zaken bij het in kaart brengen.

· Veldtoewijzing - toewijzing van tabelvelden binnen een reeds gedefinieerde tabeltoewijzing. Het resultaat van dit werk is een veldkarteringsregister.

Als onderdeel van deze fase moeten ook mogelijke werkzaamheden op het gebied van gegevensnormalisatie worden uitgevoerd.

5. Transformatieregels voorbereiden

In tegenstelling tot de voorgaande fasen is deze fase technisch en omvat het werk van de contractontwikkelaar.

Op basis van de overeengekomen veldkarteringsregisters ontwikkelen de specialisten van de opdrachtnemer regels voor datatransformatie.

Voor operationeel werk tijdens de voorbereidende fases van de migratie en verder, tijdens test- en eindmigraties, is het belangrijk dat er een handige omgeving is voor het ontwikkelen van regels (scripts) voor datatransformatie en een omgeving voor het omzetten van brondata in te laden data.

De vereisten voor deze omgeving zijn onder meer:

· Gemak en snelheid van ontwikkeling van transformatieregels;

· Snelheid van dataconversie. De invoer- en uitvoerbestanden kunnen honderdduizenden regels lang zijn!

· Mogelijkheid om tegelijkertijd met meerdere invoerbestanden te werken;

· Mogelijkheid om transformatieregels in afzonderlijke bestanden op te slaan.

Voor onze migratieprojecten hebben wij een gespecialiseerd ontwikkelaarswerkstation ontwikkeld, met de standaard 1C Query Console-verwerking als basis.

De verwerking van de Query Console is verbeterd, zodat directe query's naar xls-bestanden mogelijk zijn.

Hier is een voorbeeld van het combineren van twee xls-bronbestanden Medewerkers.xls

En Activiteiten.xls met pagina's:

Afschrijvingen

En Ontvangsten:

Merk op dat het voorbeeld kunstmatig is, speciaal geselecteerd om alle mogelijke stadia van transformatie van gegevensbronnen te demonstreren.

De technologische volgorde van transformatiebewerkingen is hier als volgt:

Met behulp van de Access SQL-querytaal (die aanzienlijke extra mogelijkheden biedt vergeleken met de 1C-querytaal) wordt een initiële query gemaakt die gegevens uit het xls-bestand extraheert naar de 1C-omgeving. Tegelijkertijd zijn in dit stadium al verschillende controles en normalisatie van gegevens mogelijk.

ADO-gegevenstoegangstechnologie biedt hoge snelheid.

Rijst. 3

2. Query in 1C-taal - de hoofdquery die het veldtoewijzingsalgoritme implementeert. En ook: verrijking van gedownloade data met data uit de 1C database, hergroeperen, samenvoegen met de resultaten van queries naar andere bron-xls-bestanden, etc.

3. Indien nodig nabewerking van het resultaat van de 1C-aanvraag. Geïmplementeerd met behulp van een script in 1C-taal.

Hier implementeren we bijvoorbeeld de toevoeging van de regel “TOTAAL” in de bedragkolommen.

4.Schrijf de definitieve gegevensset in een xls-bestand.

Over het algemeen bestaat de uitvoer uit definitieve bestanden die in de doel-1C-database moeten worden geladen.

Met deze tool kunt u ook regels voor gegevensconversie opslaan in een afzonderlijk XML-bestand:

Daarnaast is het mogelijk om te werken V batch-modus, wat vooral belangrijk is als er een grote hoeveelheid heterogene migratiegegevens is.

Tijdens de voorgaande fasen eindigt het voorbereidende deel van het werk doorgaans: alle gegevensbronnen worden geïdentificeerd, brongegevens worden gedownload uit de bronnen, downloadsjablonen worden voorbereid in de doeldatabase, gegevenstoewijzing wordt voorbereid en ten slotte worden scripts voor gegevenstransformatie ontwikkeld. .

Opgemerkt moet worden dat u vóór de definitieve migratie zeker verschillende tests moet uitvoeren. Tijdens testmigraties identificeert de Contractant samen met de Klanten:

Conversiefouten, fouten bij het laden van gegevens

Voer een voorlopige beoordeling uit van de kwaliteit van de gegevens die in het doelsysteem zijn geladen

Op basis van de resultaten van testmigraties maken/bijwerken zij een definitief migratieplan

7. Gegevensafstemming

De kwaliteit van de gedownloade gegevens moet zowel na testmigraties als aan het einde van de uiteindelijke migratie worden gecontroleerd. Tijdens de afstemming kunnen de volgende indicatoren worden gecontroleerd:

· Samenloop van totaalbedragen voor saldi, volgens documenten;

· Kwantitatieve overeenkomsten, bijvoorbeeld het aantal besturingssystemen;

· Correct invullen van individueel geselecteerde entiteiten;

Houd er rekening mee dat bepaalde controles op het migreren van gegevens en problemen met de normalisatie van gegevens tijdens alle migratieprocessen moeten worden opgelost. Je moet jezelf altijd afvragen wat er in de huidige fase moet gebeuren om fouten in volgende fasen te voorkomen.

Bijvoorbeeld:

· Controleer op duplicaten van sleutelvelden. Het kan en moet worden uitgevoerd op de originele gegevens;

· Dwang van veldtypen;

· Referentiële integriteit;

· Wiskundige inconsistenties. Bijvoorbeeld het controleren op lege numerieke velden waarin tijdens de transformatie de verdeling is gepland;

· Over het algemeen worden de verplichte velden ingevuld;

· Vervanging van onjuiste karakters. Bijvoorbeeld Engelse karakters in Cyrillische velden (“o”, “a”, “e”, enz.). Dit geldt vooral voor sleutelvelden!

· Controleren van de waarden van stringvelden op overeenstemming met de typen van het ontvangende systeem (lengtebeperkingen)

Nadat de definitieve migratie is voltooid, wordt volgens een vooraf bepaalde migratiestrategie en migratieplan een besluit genomen over de verdere werking van de historische systemen.

Vaak wordt de operatie direct na de laatste gegevensafstemmingen en het vastleggen van het succes van de migratie voltooid - gebruikers van het nieuwe systeem houden niet langer records in twee systemen parallel bij, maar stappen volledig over op het nieuwe systeem. Tegelijkertijd blijft de toegang tot het oude systeem in de leesmodus behouden.

In sommige gevallen kan parallelle werking van twee systemen plaatsvinden tijdens de proefperiode (TE) en zelfs daarna. De kwestie van parallel werk van gebruikers in twee systemen hangt nauw samen met de kwestie van de mogelijkheid om terug te keren naar het oude systeem als de migratie (of, in het algemeen, de werking van het nieuwe systeem!) als onbevredigend wordt beschouwd.

Conclusie

Concluderend zou ik willen opmerken dat als het gaat om het migreren van grote transactionele systemen, die veel 1C:Enterprise-configuraties omvatten, de transitie naar een nieuw systeem zeer arbeidsintensief kan zijn.

Daarom moet eraan worden herinnerd dat een dergelijk project een zorgvuldige voorbereiding vereist en vergezeld moet gaan van een individueel plan. Ongeacht het type systemen dat wordt gemigreerd, de databasevolumes, enzovoort, ziet het algemene migratieschema er echter vrijwel identiek uit.