Technológia migrácie údajov vo veľkých projektoch. Minimálna metodika migrácie databázy

ako implementovať zadarmo

Migrácia na bezplatný softvér ako migrácia na novší operačný systém. Ako príklad môžete spomenúť vzhľad prvých možností Windows v našej krajine. NO menej jasného príkladu - migrácia v systéme Windows NT, ideológia práce, v ktorej sa z Windows 9x prudko líšila. Môžete dať ďalší príklad - každá nová verzia balíka MS Office sa líši od predchádzajúcej nielen rozdielov v rozhraní, ale aj formátoch súborov. Takže úloha migrácie je relevantná aj v takomto prípade, keď sa používa od jedného výrobcu.

Tento článok navrhuje všeobecný opis metodiky migrácie s pokrytím významných okamihov. Všeobecná zásada migrácie je premyslená, starostlivá implementácia procesu postupnými zmenami. Migrácia sa skladá z niekoľkých logicky integrálnych miest, etáp.

vytvorenie pracovnej skupiny (ktorá robí)

Pri vytváraní migrácie je potrebné zabezpečiť riešenie problémov technického aj netechnického charakteru.

Je dôležité zvážiť právne problémy, ktoré sú nedávno veľmi dôležité pre niektoré krajiny CIS, najmä Ukrajina. V niektorých prípadoch, inteligentne diskutovať o administratívnych úlohách vzťahu "zamestnávateľa-užívateľského administrátora". Historicky tieto vzťahy nie sú dostatočne regulované vnútornými firemnými pravidlami a pokynmi.

V procese prípravy materiálu sa konverzácie uskutočnili s odborníkmi v oblasti bezpečnosti, počítačových zákonov a správcov systému. Prevažná väčšina vyhlásila potrebu dokumentárnych pravidiel dizajnu pre používateľov s informačným systémom organizácie.

Správne plánovanie zahŕňa aj riešenie finančných otázok. Je potrebné posúdiť náklady na legalizáciu existujúceho informačného systému, náklady na zavedenie nového, posúdiť náklady na vlastníctvo v blízkej budúcnosti.

Akýkoľvek projekt, vrátane migračného projektu, môže čeliť podhodnoteniu ľudského faktora. Prirodzene sa bude vyžadovať použitie metód riadenia ľudských zdrojov. Väčšina najznámejších oprávnených správcov systému a manažérov IT nie je odborníkmi v personálnych manažmente alebo finančných oblastiach. Podobná komplexná úloha nemôže byť vyriešená tým istým IT oddelením.

Prvá úloha na ceste k migrácii na nový, cieľový systém je vytvoriť pracovnú skupinu plánovania migrácie. Táto skupina je zodpovedná za vykonávanie migrácie, a preto musí mať dosť široké právomoci.

Účelom projektu je vybudovať ekonomicky odôvodnenú IT infraštruktúru. Dobrým kandidátom na pozíciu vedúceho pracovnej skupiny bude najlepším manažérom podniku alebo organizácie, napríklad - finančný riaditeľ. Samozrejme, táto skupina zahŕňa hlavu oddelenia IT, ktorá vlastní víziu celej IT infraštruktúry, a to tak v momente aj v perspektíve. Ako súčasť skupiny sa vyžaduje skúsený správca systému, najlepšie so skúsenosťami s prevádzkovým softvérom. Veľkosť skupiny nemožno odhadnúť - v niektorých prípadoch sú zapojení aj iní zamestnanci spoločnosti. Je možné prilákať poradcu tretej strany so skúsenosťami, alebo - špecializácia na takéto rozhodnutia spoločnosti. Výsledkom tejto skupiny je podrobný migračný plán s posúdením hodnoty migrácie. Buď - vysvetlenia neefektívnosti migrácie pre slobodné riešenia pre organizáciu.

výskum (čo je)

Prvým krokom by mal byť audit - opis existujúceho (dedičného) systému.

Nie je žiadnym tajomstvom, že v rokoch schválených "Avrorom" informatizácia, bez toho, aby sa zohľadnil návratnosť, ktorý sa vynaložil na fondy, bol výsledok spravidla nielen ekonomicky, ale aj technologicky nevyvážené systémy. Audit Enterprise Software je revíziou nainštalovaných programov, určenie súladu s ich obchodnými požiadavkami.

Výsledkom procesu auditu je:

Opis technických vlastností inštalovaného softvéru;

Zoznam identifikovaných rizík spojených s používaním nelicencovaného softvéru;

Počítanie nákladov na získavanie licencií na inštalovaný softvér;

Počítanie nákladov na odstránenie nelicencovanej a inštalácie licenčného softvéru;

Stanovenie uskutočniteľnosti ďalšieho používania softvéru;

Zoznam identifikovaných rizík spojených s používaním softvéru;

inventár

Niektoré štúdie ukazujú, že väčšina organizácií organizácií venuje väčšiu pozornosť funkčnosti použitého softvéru a oveľa menej - práva na použité výrobky sú splnené.

Bohužiaľ, vo väčšine organizácií neexistuje nová kultúra. Niekedy aj zástupcovia IT služieb nevedia, čo a kde inštalované na počítačoch od pracovníkov a obyčajní zamestnanci nezávisle rozhodujú a vytvárajú softvérové \u200b\u200bprodukty získané z pochybných zdrojov.

Inventár softvéru vám umožňuje identifikovať nelicencovaný softvér v organizácii. Treba zdôrazniť, že táto udalosť je vždy prospešná. Výsledok inventára možno použiť na odhad nákladov na legalizáciu podľa oboch použitia bezplatného a používania bez bezplatného softvéru.

Organizácie sa často zaujímajú o jasné finančné plánovanie nákladov na používanie a vývoj softvéru. Záujem špičkových manažérov v takýchto takýchto detailoch je pomerne zrozumiteľný - vrcholové riadenie spoločností má záujem o otáčanie softvéru v majetku spoločností, ktoré sa berú do úvahy, sa monitorujú a rozvíjajú sa podobne ako iné druhy aktív.

Audit postupu, ktorý je spravidla pomerne dlhý čas, vyžaduje sa v štádiu analýzy vysoko kvalifikovaných pracovníkov a vedomostí o rôznych konkrétnych informáciách. Odporúčanie môže byť odvolaním na spoločnosť, ktorá sa špecializuje na tieto služby. Avšak, je celkom možné audit IT oddelením.

V niektorých organizáciách je to nepohodlné (často nie je možné) vykonať rozsiahly inventár softvéru. Dôvody môžu byť veľkosť organizácie alebo bezpečnostnej politiky. Je potrebné nájsť kompromis medzi účinnosťou zásob a faktormi komplikujúcim takýto proces.

Môžete zvážiť dve možnosti pre audit. Prvá možnosť je kompletný audit o tom, ktorý všetky počítače, lokálna sieť a dokonalosť študujú. Výhodou tejto metódy je vysoká presnosť, nevýhoda - veľké náklady, vysoký čas a nepríjemnosti pre používateľov. Ďalšie výhody tejto metódy je schopnosť identifikovať nezávisle nainštalované užívateľmi softvéru a preskúmať používateľské požiadavky na softvér na svojich pracoviskách pomocou špeciálne pripravených dotazníkov. Druhou možnosťou je audit niektorých typických výpočtových nástrojov, lokálnej siete a dokonalosti. V rovnakej dobe, voľba auditu objektov je spravidla diktovaná funkčnými povinnosťami používateľov. Takáto metóda aproximácie výrazne znižuje náklady na inventár, ale má veľkú chybu.

Malé organizácie môžu vykonať audit manuálne a informácie o počítačoch a serveroch, ako aj softvér nainštalovaný na nich do elektronickej jednoduchej tabuľky. Zároveň by ste mali špecifikovať prítomnosť alebo absenciu potrebných licencií, autentifikácie a certifikátov autorských práv pre každý z nájdeného softvérového produktu.

Pre stredné a veľké, je možné odporučiť použitie špecializovaného softvéru alebo pozvať organizáciu tretej strany, ktorá sa špecializuje na podobné služby. V procese vytvárania dokumentu sa uskutočnili práca na preskúmaní automatického inventára softvéru a hardvéru (Gasp, PC Inventory, MSIA). Exponentný Navigator (http://www.e-x.ru/pages/expnav.html) môže byť odporúčaním (http: //www.html), exponent.

Exponentný Navigator

Produkt je určený na revíziu zariadení a softvéru cez sieť. Počítačové informácie zahŕňajú informácie o doplnkoch (procesor, základná doska, pevné disky, pamäťové moduly, grafická karta, sieťové karty, tlačiareň a iné zariadenia), operačný systém, ovládače a softvér.

Podľa tvorcov programu, po organizovaní automatického zhromažďovania počítačov je možné zobraziť a organizovať tieto informácie, pripraviť vytlačené správy a webové publikovanie, vyložiť údaje do programu Microsoft Excel, XML a iné formáty. Schopnosti:

Automatická diagnostika konfigurácie počítača;

Automatická zbierka informácií o sieťových počítačoch;

Stanovenie inštalovaných zariadení;

Definícia inštalovaných programov;

Definícia charakteristík súborov;

Rozšírené triedenie, vyhľadávanie a výber údajov;

Príprava tlačených správ;

Vývozné údaje v MS Excel;

Automatická generácia webových publikácií.

Vo voľnej verzii programu existuje limit - účtovníctvo na 25 počítačov; Cena licencií je $ 1 na 1 počítač.

dizajn (čo chceme)

Spracované výsledky štúdie existujúceho systému sú základom pre modelovanie nového, cieľového systému. Táto otázka je mimoriadne dôležitá a komplikovaná. Kompiruje zváženie tejto otázky a historicky zriadeného nedostatku známeho s slobodným softvérom, najmä Linuxom, väčšina IT manažérov a správcovia systému.

Existuje veľa literatúry, vrátane rusky-hovoriť, o Linuxe, ktorá opisuje výhodu tejto platformy z technologického hľadiska. Všetky tieto výhody sú však dôležité s hlavnou otázkou - existencia širokej škály aplikovaných rôznych smerov. Dlhodne, mýtus je rozšírený, že pod platformou Linux je obmedzený počet aplikovaných softvér pre používanie firemného používania, vrátane kancelárskej automatizácie. V ohromnej väčšine sú tieto mýty vytvorené a poháňané tvorcami a predajcami proprietárneho softvéru a majú málo spoločného s realitou. DEBUBE THERT MYTHUJÚCEHO NIE JE HLAVNÝM CIEĽOM TEJTO KNIHY. Stojí však za zmienku, že napríklad zemepisná šírka aplikovaného softvéru je absolútnym fantómom, pričom zohľadní zavedené historicky normy pre výmenu dokumentov. Takže, napríklad skutočný úrad kancelárskeho editora je Microsoft Office, Raster Graphics Editor - Adobe Photosop a Corel Carres je vysoko distribuovaný ako vektorová grafika.

Ďalšou otázkou je, že redundantná funkčnosť proprietárnych výrobkov nie je potrebná potrebám trhu, ale stanovisko obchodníkov. A pre túto redundantnú funkčnosť užívateľ zaplatí pomerne veľké peniaze: náklady na licenciu na právo používať programy, ktoré zvyšujú zložitosť prevádzky a zvýšených požiadaviek na hardvér.

Nedávno sa situácia zmení - objaví sa hmotnosť informácií venovaných aplikácii Linuxu. Pravdepodobne najlepší materiál bude tento dokument :-), v ktorom sa plánuje zvýrazniť mnohé administratívne a technické otázky.

Avšak, momentálne sa dokument vytvára a informácie nájdete v rôznych zdrojoch. Je nemožné prejsť materiálmi Valery V. Kachurov, Neskov Artem "Analógy programov Windows v Linuxe - tabuľka zhody." (http://linuxshop.ru/linuxbegin/win-lin-soft/). Tento zdroj obsahuje veľa cenných informácií. Zdá sa, že autori túto prácu opustia. Táto časť stránky je pravidelne nedostupná, ale kópia tabuľky nájdete na adrese http://www.brif.net/modules.php?name\u003dLinwin. Môžete informovať zdroje Open Source Applications Foundation
(http://www.osafoundation.org/), najmä http://www.osafoundation.org/desktop-Linux-overview.pdf.

Výsledkom je:

Vytvorenie prototypu pracovných staníc;

Počítanie nákladov na licencie na navrhovaný softvér;

Učenie používateľa;

Vytvorenie príkladného plánu implementácie kalendára;

Zoznam rizík v zavedení slobodného softvéru;

Podporovať voľné riešenia;

Počítanie ekonomickej efektívnosti nového systému po dobu až piatich rokov.

pilotný projekt (kontrola topánky)

Vzhľadom k veľkému počtu faktorov v zdedenom systéme, sa veľký počet užívateľov, ktorí potenciálne ovplyvňujú migráciu, odporúča sa experimentálne plnenie migrácie v malom meradle - pilotný projekt. Táto etapa je potrebná na overenie a nastavenie plánov migrácie a prototypu nového systému. Je to pilotný projekt, ktorý je základom pre rozhodnutie o zavedení nového informačného systému založeného na SPO. Druhou hodnotou pilotného projektu je schopnosť informovať používateľov o novom systéme, aby ste získali spätnú väzbu od užívateľov. Tretím argumentom v prospech pilotného projektu bude možnosť experimentálne určiť presnejšie náklady projektu.

Pri výbere testovacieho objektu musíte nájsť zlato stred. Po prvé, zvolený objekt musí poskytnúť spoľahlivé údaje na vyhodnotenie. Po druhé, pilotný projekt by nemal mať kritický vplyv na podnikanie.

V tomto štádiu sú tiež vyškolení systémových administrátorov a koncových užívateľov: Prototyp metodických materiálov, dokumentácie, zdroje na internete. Odporúča sa, aby používatelia, ktorí sa zúčastňujú na pilotnom projekte na "Unload" a umožňujú súčasť času na používanie nového systému.

Experimentálna fáza je najmä v dopyte:

Ak nie je preukázaná možnosť migrácie používateľov z dedičného systému do nového systému;

Ak existuje vlastný skepticizmus, ktorý bude môcť spomaliť proces migrácie;

Organizácia nemá korporátnu kultúru (ktorá je bohužiaľ distribuovaná v CIS);

Ak existujú obmedzené zdroje na rozsiahlu migráciu;

Organizácia je veľká a mnohí používatelia nie sú zapojení do experimentálneho projektu;

Ak sa zdedené proprietárne systémy rýchlo vyvinuli technické podmienky aj na zníženie nákladov;

Plne ekonomický účinok migrácie sa nenachádza.

Na úspech, pilotný projekt:

By sa nemali vzťahovať na kritickú oblasť podnikania;

Musia byť dostatočne dôležité pre podnikanie;

By nemali vyžadovať prechodný zdroj ľudí, ktorí sú už časovo obmedzené;

Musí mať významnú skupinu podpory;

Musí sa poskytnúť spätná väzba od užívateľov (systémy help desk);

Nemalo by byť v oblasti iného obmedzeného (napríklad dôležitého obdobia pre podnikanie).

V závislosti od veľkosti organizácie sú možné jedno alebo viac experimentálnych etáp, čo umožňuje presnejšie určiť riadky a náklady na migráciu do voľného. Je dôležité odhadnúť svoje výsledky a určiť, či vízia a účel praktického alebo ich by sa mali zmeniť, alebo možno aj vľavo. Údaje z týchto pilotných projektov by sa mali používať na úpravu plánov a počítania konečných nákladov. V procese experimentu potrebujete vylepšiť otázky:

Opis prototypu pracovných staníc;

Popis konkrétnych používateľských nastavení:

Priemerné náklady na nasadenie typu staníc;

Prenos údajov z dedičného systému na nový;

Učenie používateľa;

Počítanie nákladov na implementáciu softvéru;

Podporte bezplatné riešenia.

plánovanie (čo a ako)

1. Vytvorenie plánu migrácie. Plán migrácie musí odpovedať na otázky:

Popis fáz konštrukcie systému;

Definícia potrieb podpory;

Opis ukončenia migrácie.

V skutočnosti sa vykoná konečná voľba, keď dôjde k migrácii. Schvaľuje odhad migračných nákladov.

2. Opis fázy konštrukcie systému. Mali by sa vykonať vyhodnotenie fáz fáz budovania systému, ktoré by mali byť poskytnuté priority vlastného potrebám.

Plán musí byť zodpovedný za tieto otázky:

Do akej miery a aké etapy by mal byť systém nainštalovaný a nasadený, aby sa maximalizoval potreby používateľov?

Čo je potrebné pre každú fázu migrácie do nového systému od organizácie zákazníkov a užívateľov používateľov?

Aký bude vplyv a riziko používania systému v každej fáze prírastku?

Fáza nasadenia systému musia byť jasne určené z hľadiska migrácie; Zákazníci, vývojári a užívatelia musia byť oboznámení. Hodnotenie rizika musia byť ukončené pred uzavretím plánu výstavby systému. Je potrebné zabezpečiť, aby boli hodnotenia plánovania primerané, prístup je dobre koncipovaný v súlade s prioritami organizácie a potenciálny vplyv na zákazníkov a užívateľov je prijateľný.

3. Stanovenie potrieb podpory. Je potrebné zabezpečiť optimálnu úroveň podpory na pomoc používateľom používať nový systém. Okrem toho používatelia často vyžadujú podporu, aby im pomohli pochopiť všeobecné schopnosti (možnosti) cieľového systému.

Otázky, ktoré je potrebné vyriešiť, zahŕňajú: \\ t

Aké učenie a pomocní používatelia budú vyžadovať?

Aká je celková úroveň podpory migrácie, ktorú budú potrební použiť úspešnú migráciu?

Ako dosiahnuť prijatie cieľového systému pomocou užívateľov a vyhnúť sa odolnosti používateľov na implementáciu nového systému?

Ako budú hlásené zákazníci a používatelia, ktorí nevyhnutné zmeny v znakoch systémov a služieb?

Je možné podporovať voľné riešenia IT jednotky organizácie alebo najlepšou voľbou bude outsourcing?

Plán migrácie by sa mal zamerať na riešenie týchto problémov, plánovanie užívateľskej podpory v oblastiach:

Elemental komunikačný systém;

Služby technickej pomoci pre nové systémy;

Technická pomoc používateľom migrujúcim do nového systému;

Užívateľské príručky pre prechod a následné obdobia;

Učenie pre používateľov vo vzdelávaní a prispôsobovaní sa novému systému, vykonávať rovnaké druhy úloh;

Schopnosť testovať používanie nových systémov;

Ukážky používania nových systémov, ktoré zobrazujú existujúce užívateľom zdedené systémy, ako nový systém funguje a ako môžu vykonávať porovnateľné úlohy;

Prekonávanie súčasných operačných problémov.

V štádiu tréningu používateľa budete venovať osobitnú pozornosť tým, ktorí sú podporovateľom starého systému a / alebo súpera nových systémov.

4. Opis ukončenia migrácie. Po vyplnení každej novej fázy nasadenia a odbornej prípravy by vývojári a implementáci mali zabezpečiť, aby používatelia migrátovali tak pohodlne, ako je to možné na nový cieľový systém. Plán migrácie by mal zabezpečiť urýchliť silu migrácie a čo najskôr odstrániť zdedený systém.

Musí sa poskytnúť dodatočné úsilie, že môže byť potrebné pre "najnovšie súbory" a iných používateľov, ktorí zažívajú nepredvídané problémy. Ďalším aspektom tejto činnosti sa odhaduje čas a náklady na dokončenie prechodu všetkých používateľov do nového systému a odstrániť staré systémy vytvorené na proprietárnom softvéri z oblasti licencie.

Riadenie organizácie, vývojárov a nástrojov by malo zvážiť zahrnutie niekoľkých prístupov, aby pomohli migrovať na zdedené systémy používateľov:

Správa každej skupine používateľov, as a kedy musia vykonať prevod svojich úloh do nových systémov, ako sa pracovné zaťaženie zmení na obdobie migrácie s dedičnými systémami;

Stanoviť stimuly na krok, aby sa úplne prepínať na nový voľný systém a eliminovali závislosti od dedičných systémov;

Poskytnite pomoc (softvér a ďalší personál) na konverziu zdedených údajov do nového systému; - poradie výstupu z prevádzky dedičných systémov;

Archivácia zdedených dát a skladovanie.

migrácia (do)

Všetko, čo zostáva v poslednej fáze, je pracovať podľa plánu.

Aktívne spravovať a monitorovať procesy migrácie:

Nastavte kritériá merania a monitorujte kroky migrácie a náklady na zdroje na migráciu;

Urobte si periodické recenzie situácie a zoznámte sa s nimi, podľa orgánu a organizačnej politiky, záujemcov (manažment, projektoví manažéri a sponzor);

Nastavte systém sledovania (sledovanie) na riadenie podpory procesov (pokroku), problémov, riešení a iných obchodných otázok súvisiacich s plánovaním migrácie a vykonávania plánov.

Vadim Mashkov, UA-FOSS, [Chránené e-mail]

V tomto článku by sme chceli systematizovať naše skúsenosti s vykonávaním migrácie údajov vo veľkých firemných projektoch súvisiacich s prechodom zákazníkov pracovať v konfiguráciách "1c: Enterprise 8".

V rovnakej dobe, hlavný dôraz v článku sa v prvom rade uskutoční technologická zložka procesu migrácie. Ovplyvnená aj organizačná zložka, ale v menšej miere.

Pojmy a definície

V rámci migrácie údajov je obvyklé pochopiť konečnú sekvenciu práce, projekt zameraný na jednorazový hromadný pohyb údajov zo zdrojových systémov (historických systémov) do systému prijímača. V tomto prípade je ukončená prevádzka týchto údajov v zdrojových systémoch.

Malo by sa rozlišovať migrujúce údaje z integrácie údajov. Integrácia, na rozdiel od migrácie, je trvalá časť IT architektúry a je zodpovedná za toky dát medzi rôznymi systémami a dátovými skladmi - a je procesom, a nie implementácia projektu.

Systém migrácie vo všeobecnosti vyzerá takto:

Obr. jeden

Historické systémy - Zákaznícke firemné databázy, ktoré sa plánujú, aby boli plne alebo čiastočne nahradené pri vykonávaní nového systému.

Systém prijímača - Cieľový systém, ľubovoľná konfigurácia "1C: Enterprise 8".

Počiatočné údaje - Údaje vyložené z historických systémov do ľubovoľného formátu XLS. V tomto prípade je formát XLS reprezentovaný ako jeden z najvhodnejších, pretože možnosť vykladania do súboru XLS je prítomná v mnohých účtoch "predchádzajúcich generácií".

Ako moderná alternatíva je možné zvážiť formát súboru XML.

Existujú aj možnosti používania medziľahlej databázy.

Transformácia, konverzia - Proces konverzie zdrojových údajov na údaje na prevzatie. Transformácia dát sa vyskytuje v súlade s šablónmi zaťaženia. Výsledkom transformácie sú údaje na prevzatie.

Údaje na stiahnutie - Údaje určené na zavádzanie do systému prijímača. V tomto článku, ako aj počiatočné údaje, XLS-formát.

Šablóny údajov na stiahnutie - Popis dátových tabuliek na prevzatie do cieľového systému.

Etapy migrácie

Zvážte postupný proces prípravy a vykonávania migrácie.

Nasledujúce položky zahŕňajú organizačné fázy migrácie:

· Stanovenie migračnej stratégie. V tomto štádiu sa dodávateľ a zákazník dohodnú na technológii migračnej práce;

· Určenie zloženia pracovnej skupiny migrácie. Pracovná skupina by mala zahŕňať špecialistov a umelca a zákazníka, dostatočne známy s prácou historických systémov (od zákazníka) a cieľový systém (dodávateľom);

· Predbežný plán migrácie. Plán migrácie pozdĺž projektu sa bude opakovane upraviť;

· Obdobia údajov o vykladaní údajov z historických systémov, objemov údajov. Obdobia zníženia údajov pre migrácie, dátumy testov a konečných migrácií. Tieto informácie možno pripísať plánu migrácie;

· Zloženie údajov, ktoré sa majú migrovať. Referenčné údaje, klasifikátory, transakčné údaje, zvyšky, obrat atď.;

· Otázky overenia kvality, správnosť a integritu údajov v procese migrácie a podľa výsledkov;

· Otázky, ktoré sa majú vrátiť do predchádzajúceho stavu v prípade zlyhania.

Dajte nám prebývať na technologických štádiách migrácie.

Obr. 2.

1. Príprava šablón zaťaženia dát

Šablóna dátového zaťaženia obsahuje technické popisy dátových tabuliek na prevzatie, algoritmy a pravidlá zaťaženia pre aktuálnu šablónu.

Každá šablóna je všeobecne navrhnutá pre jednu alebo viac súvisiacich tabuliek v systéme prijímajúcej cieľ.

Šablóna označuje:

· Popis všetkých polí XLS na stiahnutie, vrátane:

o Názov poľa

o Znamenie Povinné pole vyplniť

o Príklad výplne

o Poznámka

· Popis pravidiel na prevzatie tabuľky cieľového systému na základe údajov pre načítanie (relácie v prípade viacerých súvisiacich tabuliek, vyhľadávacích algoritmov pre kľúčové polia atď.)

· Popis výplne priamo polí cieľových systémových tabuliek v prípade, že sa niečo odlišuje od prenosu údajov "jeden k jednému" z dátového súboru na stiahnutie. Napríklad pre referenčné polia.

V procese práce v tomto štádiu musí dodávateľ tiež pripraviť dátový nakladač na sťahovanie dát. V prípade práce s XLS súbormi nie je táto úloha mimoriadne ťažké.

2. Dôkazy o zdrojoch údajov

Táto fáza môže začať s predchádzajúcim krokom "1. Príprava šablón na prevzatie údajov. "

Ako súčasť tejto fázy, špecialisti zákazníka určujú, ktoré systémy a ktoré údaje môžu byť vyložené. Mali by ste tiež určiť, aké údaje pravdepodobne Môže byť potrebná.

Spravidla vo veľkých migračných projektoch môže detekcia úplného vyčerpávajúceho zoznamu zdrojov údajov obsadiť dostatočne dlhú dobu a vyskytuje sa ako práca v nasledujúcich etapách.

Často je situácia, keď, aby sa zabezpečila ďalšia integrita informácií, niektoré údaje musia byť prevedené z tlačených zdrojov (digitalizovať) alebo dokonca zadať tabuľky zo slov kľúčových zamestnancov zákazníkov.

Avšak, v tomto štádiu musíte sa pokúsiť identifikovať čo najviac dát.

3. Zaťaženie zdrojových údajov

Proces vykladacích údajov z historických systémov môže mať dostatočný čas, najmä ak existuje mnoho systémov, sú odlišné a rôzne divízie zákazníka sú za ne zodpovedné. Je potrebné vziať do úvahy moment v skúške a konečných migráciách.

Zdá sa, že najpohodlnejšia možnosť vykladajte súbory XLS. Mnohé staré IT-systémy podporujú takúto možnosť.

K dispozícii môžu byť aj možnosti vyloženia vo formáte CSV, formátov DBF, XML a ďalších.

Stojí za zmienku, že z jedného dôvodu alebo iné (bezpečnostné otázky, napríklad) zákazník nemôže vždy poskytnúť údaje o nahrávaní v tomto štádiu! Iba dátová štruktúra a niekoľko testovacích položiek. Takáto situácia môže vzniknúť, že počas skúšky a konečných zaťaženia sa zlyhá údaje o kvalite nájdu v zdrojových tabuľkách, čo povedie k neplánovaným chybám.

Na minimalizáciu tohto problému by sa mal vopred stanoviť objem skúšobných vykladaní z historických systémov.

4. Mapping Data

Mapovanie (mapovanie dát) - všeobecne proces mapovania údajov historických systémov a prijímacieho systému. To znamená, že zdrojové údaje a údaje na prevzatie.

Štadióna mapovania je najviac časovo náročná etapa a môže trvať viac ako 50% všetkých prác na úlohe migrácie.

V tomto štádiu je plne zapojená celá pracovná skupina projektu migrácie.

V procese mapovacích údajov je potrebné zdôrazniť formácie mapovacích tabuliek a mapovacích polí.

· Mapovacie stoly alebo mapovacie šablóny - Mapovanie zdrojových dátových tabuliek a šablón údajov na prevzatie. Súlad môže byť ako 1: 1 a N: n. V dôsledku tejto práce je register mapovacích tabuliek zostavený a udržiavaný. Tento čiastkový krok je potrebný pre ďalšie podštartovanie mapovacích polí a sledovať celkový stav mapovania.

TEAM GROUP 1C.

Názov šablóny 1c

Názov súboru

zdroj

Pravidlá pre vytvorenie zdrojového súboru

Zodpovedný

Postavenie

Poznámka

NSI

Template_

Nomenklatúra

Nomenk

lasturózne .xls.

V systéme n Nastavte výber
. Uložiť v txt
. Otvorené v XLS, Stĺpce - Text
. Prvý reťazec - klobúk
. Počet stĺpcov - 15
. Skontrolujte počet riadkov v TXT a XLS
. Názov listu je vždy "list1"

IVANOV I.I.

v práci

· Mapovanie polí - Mapovanie stolových polí v rámci už definovaných mapovacích tabuliek. Výsledkom tejto práce je register mapovacích polí.

ПП

Cl. lúka

Povinný

Názov poľa 1C šablóny "template_namenclature"

Popis

Názov poľa "nomenclature.xls"

Plniaci algoritmus

Kód

Kód referenčnej položky

Kód

názov

Áno

Táto skupina

Obsahuje jednu z hodnôt:
. 1 - pre skupiny
. 0 - Pre prvky

Ak kódová dĺžka \u003d 11 znakov a posledné 4 znaky<> "0000", potom tento prvok je "0", inak je skupina "1".

Celé meno

Názov referenčného prvku

názov

Ak skupina ETCO \u003d 1, potom "" a skupina ETCO \u003d 0, potom názov.

V rámci tejto fázy by tiež mala vykonať možné údaje o normalizácii údajov.

5. Príprava pravidiel transformácie

Na rozdiel od predchádzajúcich etapov je táto etapa technická a zahŕňa prácu developer Dodávateľa.

Na základe dohodnutých registrov mapovacích polí, odborníci umelca vyvinú pravidlá transformácie údajov.

Pre prevádzkovú prácu v procese prípravných migračných fáz a ďalej, v priebehu skúšky a konečnej migrácie, je dôležité, aby existovalo pohodlné vývojové prostredie pre dáta (skripty) transformácie dát a prostredia konverzie zdrojových dát k údajom na stiahnutie.

Zároveň zahŕňajú požiadavky na toto prostredie:

· Pohodlie a rýchlosť vývoja pravidiel transformácie;

· Rýchlosť konverzie údajov. Súbory pri vchode a výstup môžu byť stovky tisíc riadkov!

· Schopnosť pracovať s viacerými vstupnými súbormi v rovnakom čase;

· Schopnosť ukladať pravidlá transformácie na jednotlivé súbory.

Pre svoje migračné projekty sme vyvinuli špecializovaný vývojár AWP, pričom sa na základe štandardného spracovania "požiadaviek konzoly" 1c.

Spracovanie "Žiadosť Console" bola dokončená, aby bola schopná vykonať priame požiadavky na súbory XLS.

Uveďte príklad kombinácie dvoch zdrojov xls -files Zamestnancov.xLS.

Zamestnanecký kód	Priezvisko	názov	stredné meno	Dátum narodenia
2423	Ivanov	Ivan.	Ivanovich	17.11.1992
1523	Pedov	Bazalka	Aleksandrovich	04.02.1991
4363	Sidorov	Kirill	NIKOLAICH	01.05.1995
	Denisov	Denis	Denisovich	01.01.1990

a Operácie.xLS.s stranami:

Vypnutie

Zamestnanecký kód	dátum	Suma
2423	01.02.2014
1523	02.02.2014
4363	03.02.2014
	04.02.2014	100000
2423	05.02.2014
1523	06.02.2014
4363	07.02.2014	2356
	08.02.2014	140000
2423	09.02.2014
1523	10.02.2014
4363	11.02.2014	23523
	12.02.2014	80000

a Prílety:

Zamestnanecký kód	dátum	Suma
	01.05.2004
	02.05.2004
	03.05.2004
	04.05.2004







2423Dátum narodenia	Výška prijatia	Množstvo odpísania
Ivanov Ivan Ivanovich	2423	17.11.1992	1341234	1010
Petrov Vasily Aleksandrovich	1523	04.02.1991	245245
Denisov Denis Denisovich		01.01.1990	380000	320000
Sidorov Kirill Nikolavich	4363	01.05.1995	613382	26336
CELKOM:			2579861	347842

Upozorňujeme, že príklad je umelý, špeciálne vybraný na preukázanie všetkých možných etáp transformácie zdrojov údajov.

Technologická postupnosť transformačných operácií tu je nasledovná:

Používanie prístupového jazyka SQL QUERY (poskytuje významné dodatočné funkcie, v porovnaní s jazykom 1C požiadavky), je vytvorená počiatočná požiadavka, extrahuje údaje z súboru XLS na 1c. Zároveň v tomto štádiu existujú rôzne kontroly a normalizácia údajov.

Access Technology ADO poskytuje vysokú rýchlosť.

Obr. 3.

2. Účastník v 1C Jazyk - Hlavný dotaz, ktorý implementuje pole mapovacích polí. Rovnako ako: obohatenie údajov prevzatých údajov zo základne 1c, preskupenie, kombinovanie s výsledkami dotazov na iné zdroje XLS -phals atď.

3. V prípade potreby koncestuje výsledok dotazu 1C. Je implementovaný pomocou skriptu v 1c.

Tu sa tu realizuje prídavná línia "Celková" z hľadiska súm.

4. Obnovte súbor údajov o výsledku v súbore XLS.

Všeobecne platí, že na výstupe dostávame konečné súbory na prevzatie do cieľovej databázy 1C.

Tento nástroj vám tiež umožňuje uložiť pravidlá konverzie dát na samostatný súbor XML:

Okrem toho sa realizuje do práce v dávkový režimTo je zvlášť relevantné s veľkým počtom heterogénnych migračných údajov.

Počas predchádzajúcich krokov je prípravná časť práce všeobecne končí - všetky zdroje údajov sú odhalené, zdrojové údaje sú vyložené zo zdrojov, šablóny na prevzatie sú pripravené na cieľovú základňu, mapovanie dát a konečne vyvinuté skripty transformácie údajov.

Treba poznamenať, že pred konečnou migráciou by sa malo vykonať niekoľko testov. Počas testovacích migrácií Dodávateľ spolu so zákazníkmi zistí:

· Chyby konverzie, chyby zaťaženia dát

· Vykonať predbežné posúdenie kvality údajov, ktoré sa prevzali do cieľového systému.

· Podľa výsledkov testovaných migrácií je základom konečnej migrácie vypracovaný / aktualizovať

7. Majster údajov

Kontrola kvality stiahnutých údajov by mala byť vykonaná po migrácii testov a na konci konečnej migrácie. Počas odsúhlasenia sa môžu skontrolovať tieto ukazovatele:

· Zhody konečných sumy na pozostatky podľa dokumentov;

· Kvantitatívne zhody, ako napríklad počet OS;

· Správnosť vyplnenia jednotlivých vzorových subjektov;

Upozorňujeme, že tieto alebo iné overovanie migračných údajov, problémy s normalizáciou údajov musia byť vyriešené v celej migračnej procesy. Je vždy nutné premýšľať, čo je potrebné urobiť v súčasnej fáze, aby sa zabránilo chybám v nasledujúcich etapách.

Napríklad:

· Skontrolujte duplikát na kľúčových poliach. Môžete a musíte sa vykonať na zdrojových údajoch;

· Prináša typy poľa;

· Referenčná integrita;

· Matematické nezrovnalosti. Napríklad kontrola prázdnych číselných polí, na ktorých je naplánovaná divízia divízie;

· Vo všeobecnosti overenie povinných plných oblastí;

· Výmena nesprávnych znakov. Napríklad anglické znaky v Cyrilických poliach ("O", "A", "e" atď.) Zvlášť relevantné pre kľúčové polia!

· Kontrola hodnôt strunových polí pre súlad typu typu prijímača (limity dĺžky)

Po ukončení konečnej migrácie podľa určitej stratégie migrácie a plánu migrácie sa rozhodnutie vykonáva na ďalšie využitie historických systémov.

Využívanie je často ukončené bezprostredne po konečnom zmierení údajov a opraviť úspech migrácie - užívatelia nového systému už nie sú zaznamenané paralelne v dvoch systémoch, ale sú úplne presunuté do nového systému. V tomto prípade sa prístup do starého systému uloží do režimu čítania.

V niektorých prípadoch sa môže vyskytnúť paralelná prevádzka dvoch systémov počas skúšobnej prevádzky (OE) a ešte viac ako toto obdobie. Otázka paralelnej prevádzky používateľov v dvoch systémoch úzko súvisí s možnosťou návratu na starý systém, ak sa migrácia (alebo vo všeobecnosti, práca nového systému!) Bude považovaný za neuspokojivý.

Záver

Na záver by som chcel poznamenať, že pokiaľ ide o migráciu veľkých transakčných systémov, ktoré zahŕňajú mnohé konfigurácie "1c: podniky", prechod na nový systém môže byť veľmi časovo náročný.

Preto treba pripomenúť, že akýkoľvek podobný projekt si vyžaduje starostlivú prípravu a musí byť sprevádzaný individuálnym plánom. Bez ohľadu na typ migrovaných systémov, objemy databázy atď. Celková migračná schéma vyzerá takmer identické.

Leif Polesesen pre Intech

Automatizačné systémy pre výrobu a zber informácií o výrobných procesoch žijú relatívne dlhé. Často sú aktualizované alebo vymenené pred dosiahnutím procesu jeho životnosti. Pre mnohé spoločnosti sa správa náhrady alebo modernizácie takýchto automatizačných systémov bez zastavenia výroby zmení na skutočný hovor. Preto sa objektívna potreba modernizácie alebo výmeny ignoruje, kým sa nič nestane. Tento článok je venovaný tomu, ako to môže byť úspešne vyriešená touto úlohou, vďaka dôkladnému plánovaniu a organizácii.

Dva hlavné faktory sú podľa potreby modernizovať a nahradiť systémy priemyselného automatizácie a priemyselných informačných systémov: technická degradácia týchto systémov, ako aj zmeny v požiadavkách podnikových procesov, ktoré sú podporované týmito systémami.

Spoľahlivosť technických systémov sa časom zníži, ak spoločnosti ignorujú potrebu aktualizovať operačné systémy, databázy prostredníctvom aplikácií. Operačné riziko zlyhania zariadenia sa primerane zvyšuje.

Vďaka starostlivému plánovaniu je možné prevádzkové riziko konať na prijateľnej úrovni, okrem toho, okrem toho je zabezpečená ochrana investícií a náklady na životnosť systému sú minimalizované. Pre typickú automatizáciu alebo systém IT sa systém vykonáva len 20-40% investícií. Zvyšných 60-80% prejde na udržanie vysokej dostupnosti a prispôsobenia sa pravidelne meniacim sa požiadavkám.

Okrem hodnotenia činností potrebných na zabránenie technickej degradácii sa musia zohľadniť nové výzvy, ako aj potenciálne obchodné príležitosti. Podnikateľské prostredie sa neustále mení a vždy by sa mala zvážiť všetka možnosť zlepšenia existujúcich alebo zavedenia nových technológií. Typické obchodné príležitosti, ktoré sa môžu stať stimuly na migráciu systémov automatizácie poznámok - rýchlosť produkcie nových výrobkov na trh, konkurencieschopnosť, rast, kvalitu a dodržiavanie regulačných požiadaviek.

Dlhodobý migračný plán

Rozvoj dlhodobého systému systému Migration umožňuje spoločnostiam podporovať systémové riziká na prijateľnej úrovni. Okrem toho poskytuje riadenie rizík a včasnú podporu podnikateľských cieľov. Plán migrácie musí nevyhnutne zohľadniť takéto obmedzenia ako "najlepšie výrobné postupy", technologickú funkčnosť, nevyhnutnú jednoduchosť výroby.

Všeobecne platí, že prístup k dlhodobému plánovaniu je znázornený na obr. Plán migrácie sa vyvíja, aby sa zistilo, kedy spoločnosť chce byť za päť rokov, čo je potrebné na to, aby sa na to vyžadovalo, a či sú potrebné zdroje potrebné. Tento prístup je založený na princípoch architektonického dizajnu stanoveného v norme TOGAF, ktorý je široko používaný vo vývoji systémovej architektúry priemyselných podnikov.

Obrázok 1. Všeobecný prístup k vytvoreniu dlhodobého plánu migrácie.

Je potrebné rozlišovať medzi existujúcou architektúrou a cieľovým, žiaducim. Rozdiel medzi nimi odráža rozdiel medzi postavením spoločnosti v súčasnosti a situáciou, ktorú chce v budúcnosti prijať. Plán migrácie pripravuje cestu z existujúcej architektúry cieľov - možno prostredníctvom niekoľkých prechodných etáp.

Každá architektúra môže byť opísaná ako séria "vrstiev", ktoré slúžia na prepojenie medzi podnikmi a technológiou - ako je znázornené na obr. 1. Pozornosť musí byť venovaná nasledujúcim "vrstvám": \\ t

Obchodné ciele Toto je súčasťou celkovej stratégie plánovania práce. Umožňujú vám vybrať správny smer procesu.
Obchodný model Poskytuje kontext, v ktorom sa rozumejú výroby a obchodné procesy. Zahŕňa pravidlo na vysokej úrovni opis tokov materiálov a procesov.
Popis výrobných a obchodných procesov Je dôležité, aby úspešné uplatňovanie technológie a správneho posúdenia ich hodnoty z hľadiska podnikania.
Informácie, údaje a dokumenty Dôležité pre komunikáciu procesov a aplikácií. Zvlášť dôležitá interakcia a správa informačných tokov medzi aplikáciami.
Popisy aplikáciepovoliť požiadavky na vysokej úrovni a identifikovať rozhrania.
Definícia infraštruktúra, výpočtová technika a sieť Požiadavky (hardvér, tolerancia porúch, výkon).
Poskytnutý služby Určite požiadavky na zabezpečenie efektívneho podpory operačného riadenia a riešení.

Rozvoj migračného plánu

Vývoj migračného plánu pre celú organizáciu, alebo dokonca pre samostatnú výrobnú platformu, môže byť skutočne zložitá úloha, ktorá zahŕňa mnoho ľudí. Odporúča sa oddeliť proces vývoja do niekoľkých krokov opísaných nižšie.

Časť II.

Fáza 1: Mobilizácia

Základné ciele:

dosiahnuť spoločné chápanie úloh a cieľov
mobilizovať organizáciu, v ktorej je projekt plánovaný
detail plán, opisujúci míľniky a výsledky fázy projektu
zhromažďovať všetky potrebné / dostupné informácie
poskytnite správne pochopenie konceptov, postupov a teórie

plánované stretnutia
workshop venovaný projektu

Výsledky:

podrobný poradenský plán
spoločné ciele
prehľad procesu

Fáza 2: Analýza

Účelom etapy analýzy je:

analýza obchodných a výrobných procesov s cieľom:

Posúdiť pripravenosť zamestnancov slúžiacich systémom IT a automatizácie

Zistite potrebu dát a funkčnosti pre budúcu architektúru

Identifikujte kľúčové výhody budúcej architektúry pre stanovenie cieľov a vykonávanie ekonomického odôvodnenia

analýza existujúcej architektúry

Stanovenie existujúcich výrobných procesov v ich súvislosti s automatizačnými systémami, zber údajov, systémy riadenia výroby

Určenie existujúcich obchodných procesov a ich prepojení s automatizačnými systémami výroby

Určenie existujúcich aplikácií, údajov, logickej a fyzickej infraštruktúry, ako aj služby technickej podpory

Počas tejto fázy sa vykonáva táto činnosť:

semináre a diskusie o rôznych procesoch
podniky Návštevy na získanie kontextových informácií
semináre a diskusie venované existujúcim systémom
hodnotenie služieb na určenie stupňa ich splatnosti a dodržiavania požiadaviek nariadenia

Výsledky:

určenie existujúcej infraštruktúry
analýza Dokumentácia
zoznam nápadov o výzvach a schopnostiach novej architektúry zoznamu myšlienok o výzvach a schopnostiach novej architektúry

Fáza 3: Účel

Účelom tejto fázy je definícia a opis potrieb formulovaných počas fázy analýzy.

Riešenie alebo cieľová architektúra bude popisovať:

budúce podnikové procesy a funkcie
cieľové typy aplikácií, s ich funkčnosťou, užívateľmi, informáciami a rozhraním
požiadavky na infraštruktúru a revidované normy podpory

Počas tejto fázy sa vykonáva táto činnosť:

semináre a diskusie o zlepšovaní procesov
semináre a diskusie o zlepšení architektúry

Výsledky:

budúca architektúra (prezentácia)
stručný opis aplikácií

Fáza 4: Odôvodnenie

Cieľom štádia odôvodnenia je primárnym hospodárskym zdôvodnením na základe približných odhadov nákladov a prínosov získaných počas projektu.

Rozdiel medzi existujúcimi a žiaducimi pozíciami zvyčajne vedie k vzniku viacerých myšlienok. Odôvodnenie myšlienok umožní rozlíšiť "potrebné" z "žiaduce", a potom, aby predložil a rozvíjali myšlienky na vrcholový manažment.

Počas tejto fázy sa vykonáva táto činnosť:

približný odhad výdavkov a prínosov
prvá verzia prezentácie

Výsledky:

spoločné ciele
zmena podnikateľských nápadov
vyhodnotenie potrebných zdrojov

Fáza 5: Plán

Účelom tejto etapy je plánovať projekt založený na prioritách, zdrojoch a závislostiach:

plánovanie postupnosti štádií konsolidovaného projektu
poskytovanie zdrojov a kompetencií potrebných pre tieto kroky
projektové činnosti
dokončenie poradenstva a prevod výsledkov všetkých etáp zákazníkovi

Počas tejto fázy sa vykonáva táto činnosť:

vývojový plán na implementáciu
vývoj investičného plánu
posúdenie rizík

Výsledky:

implementačný plán
hodnotenie pracovného zaťaženia pre personál zapojený do projektu
odhad rizík projektu
investičný plán (v prvej aproximácii)
konečná verzia prezentácie projektu

Praktický príklad

Nasledujúci príklad ilustruje aplikáciu opísaného prístupu v reálnych podmienkach. Dodržiavanie dôverných podmienok sa v popise pozorovalo anonymita. Ide o pomerne veľký podnik produkujúci aktívne zložky pre farmaceutické výrobky. Výrobné zariadenia boli uvedené do prevádzky pred viac ako 20 rokmi, a hoci od tej doby sa uskutočnilo určitá modernizácia, počet zastaraných systémov vyžaduje výmenu. Automatizačné systémy budov a RSU sú v prvom rade, pretože sú založené na zastaraných technológiách, ktoré sú ťažké udržať. Okrem toho by sa výroba mala prispôsobiť novým obchodným požiadavkám, vrátane zastavenia výroby samostatných produktov a spustením iných. Vo všeobecnosti existuje potreba pracovať na migračnom pláne, ktorý sa vzťahuje na technické aj obchodné požiadavky.

Po prvé, je potrebné vytvoriť všeobecný zoznam zariadení, ktoré sa v súčasnosti používa v celom podniku. Tieto informácie sú často "skryté" v rôznych dokumentoch (a pamäte zamestnancov). Musí byť odstránený a vizualizovaný, aby sa stal základom migračného plánovania. Na tento účel sme spravidla vytvorili procesný graf procesných modulov, zobrazujúci hlavné vybavenie a pohyb surovín a materiálov v každej priemyselnej divízii. Ako samostatné vrstvy "TOP" Zariadenia ukážeme, ktoré systémy, ktoré zariadenie je podporované.

Príklad je znázornený na obr. 2. Údaje o zavedených systémoch obsahuje aj v ukladaní systému (alebo jednoducho v programe Excel) a môžu byť použité na ďalšiu analýzu a plánovanie.

Obrázok 2. Vrstva Automation vám umožňuje vyhodnotiť existujúce systémy

Pred diskusiou o migračnom pláne je potrebné určiť hlavné obchodné motívy zmien vo výrobe. V prípade posudzovaného prípadu manažment pridelil tieto motívy:

1. Stabilný a bezchybný súlad s regulačnými požiadavkami

2. Minimálne časové náklady na vstup na trh, flexibilitu

3. Úspech, konkurencieschopnosť, prevádzková dokonalosť

4. Nekompromisná kvalita

5. Výroba rastu

Tieto ciele musia byť transformované na konkrétnejšie úlohy, ktorého sa môže kvantifikovať.

Potom musíme zistiť, ako dobre existujúce systémy podporujú súčasné a budúce podnikové procesy. Na tento účel používame štandardný referenčný model (na základe série ANSI / ISA-95). Zahŕňa 19 obchodných procesov na vysokej úrovni podrobne uvedené v rozsahu, ktorá vám umožní vidieť nedostatky v ich praktickej implementácii a potrebe zmeny pre efektívne podnikanie.

Okrem toho musíme tiež vyhodnotiť technické schopnosti existujúcich systémov na podporu podnikateľských procesov v budúcnosti. Toto sa systematicky implementuje pomocou vyššie opísaného ukladania informácií. Pre každý systém, informácie o tom, čo je v úložisku (v našom prípade ide o 70 systémov), je potrebné posúdiť tieto aspekty:

Stav zariadenia (história odrazu, priemerná doba prevádzky pre zlyhanie, vek vybavenia, prístupnosť náhradných dielov)
Stav softvéru (podpora pre dodávateľov, dostupnosť dokumentácie, personálu s potrebnými kompetenciami)
Pravdepodobnosti systémov (rezervácia, priemerná životnosť pred opravou)
Posúdenie vplyvu vplyvu (poskytovanie informácií, chyby údajov, neprístupnosť)
Orientačné ukazovatele (spoľahlivosť systému, kritický význam systému atď.)

Technické hodnotenie odhalilo potrebu modernizácie a nahradenia viacerých systémov:

TP ACS je založené na obvyklých, zastaraných RSU a mnohých rôznych PLC, ktoré sú už "dozrené", ktoré nahradí.
Systém automatizácie budov je založený na novšej platforme, ale vyžaduje si aj modernizáciu na splnenie nových požiadaviek.
Počet sekundárnych systémov vyžaduje aj aktualizácie alebo dokonca výmeny.
Infraštruktúra slúži všetkým systémom si vyžaduje lepšiu segmentáciu a ochranu dodržiavania moderných bezpečnostných požiadaviek.

Časť III

Po analýze obchodných cieľov naplánovaných do budúcnosti sa ukázalo, že žiadny z existujúcich systémov zodpovedá plne potrebám budúcim potrebám. Toto porozumenie slúžilo ako dôvod na vznik viacerých myšlienok o zavedení nových technológií, ako aj výkonného systému výroby. Podľa výsledkov analýzy bolo navrhnutých 16 rôznych projektov, ktoré s dôsledným implementáciou pomôže spoločnostiam splniť budúce technické a obchodné požiadavky.

Odhaduje sa, že údržba technických prác a náklady na každý projekt sa odhaduje; Pre každý projekt pripravuje stručné jednorazové zhrnutie, ktoré môže diskutovať o riadení. (Pozri obr. 3).

Obr. 3. Jednoľúbový popis potenciálneho migračného projektu

S cieľom vybrať si prioritné projekty sa vyhodnotia potenciálne výsledky každého z nich. Výsledky sa hodnotia z hľadiska obchodných cieľov, ako aj spoľahlivosť TP ACS.

Spravidla budete musieť hodnotiť niekoľko implementačných scenárov na posúdenie celkovej potreby zdrojov a finančných zdrojov pre každý plán (obr. 7). Jedným z hlavných obmedzení, ktoré by sa mali zvážiť, sú "Windows" vo výrobnom procese, počas ktorého môžete nahradiť alebo upraviť systémy. Títo "Windows" padnú na víkend - a to je vážna "fľaša hrdla".

Obr. 7. Konsolidovaný plán migrácie

Od času nahradiť systémy a ich úpravu je vždy "na okraji", prípravok musí byť veľmi opatrný. Všetko by sa malo podrobne roztaviť. Dôležitým aspektom plánovania je overiť implementované systémy.

V prípade, ktorú ste opísali, implementácia dlhodobého migračného plánu bola vykonaná v šiestich rôznych prúdoch, pozri ryžu. osem.

Obr. 8. Organizovanie migračných projektov v šiestich rôznych prúdoch

Časť prípravku je dôkladné hodnotenie a prevencia rizík projektu. Na obr. 9 znázorňuje typické riziká charakteristické pre migračné projekty.

Obr. 9. Hodnotenie typických rizík migračných projektov

Procesy pre podporu podnikania

Prístup k riadeniu životného cyklu a plánovanie dlhodobej migrácie opísanej v tomto článku je určená potrebám podnikania. Zahŕňa hodnotenie súčasných a budúcich obchodných cieľov, ako aj dôkladnú analýzu toho, ako budú technické systémy podporované alebo nahradené za najlepšiu podporu na tieto účely. Prístup je založený na princípoch TOGAF, ktorý zabezpečuje dôsledné vykonávanie projektu v závislosti od dostupnosti rozpočtov a kvalifikovaných pracovníkov. Hodnotenie súčasných a budúcich architektúr systému je kľúčovým prvkom pri identifikácii budúcich migračných projektov. Nakoniec je potrebné dodržiavať zásady riadenia zmien v organizácii, ktoré zabezpečujú včasné zapojenie kľúčových účastníkov projektu, čo je dôležité pre úspech migračných projektov. Účinnosť tohto prístupu bola opakovane preukázaná v praxi.

Leif Poulsen) ( ), popredný špecialista v oblasti automatizácie a to v NNE Pharmaplan. Má titul workshopu v oblasti technologického manažmentu. NNE Pharmaplan Polesesen je zodpovedný za rozvoj technológií, metód a kompetencií v oblasti priemyselnej automatizácie a IT a funguje ako seniorský obchodný poradca.

PLM priemysel sa vyvíja viac ako desať rokov a v okamihu, keď sa podniky, testovanie rozhodnutí vybraných spočiatku, sa veľmi rozumne rozhodnú zmeniť existujúce PLM na druhé, alebo výrazne zmeniť konfiguráciu aktuálneho. A potom existuje otázka migrácie údajov PLM zo starého systému do nového. Ako vieme, aj vysielanie geometrických údajov samotných nie je ľahké a nejednoznačne vyriešené, migrácia údajov PLM je ešte komplikovanejšie a stále známy proces.

Ako sa to stane

Uskutočnil sa výber nového systému PLM, tím vedúcich pracovníkov s úľavou oslavuje výsledok komplexného úsilia tejto voľby. V skutočnosti, len teraz súčasná práca, plánovanie a migrácia údajov z existujúcich systémov na novú cieľovú platformu PLM. Existujúce spoločnosti obsahujú významnú časť duševného vlastníctva (IP), a preto súťažné výhody a kapitál spoločnosti. Úspech zavedenia nového systému vo veľkej miere závisí od výkonu efektívnej migrácie existujúcich údajov, inteligentných, efektívnych a včasných.

Tento scenár sa pravidelne opakuje v jednom alebo inom svete av každom priemysle. S rýchlym zlepšením technológií, posilnenie konkurenčného tlaku vedie k tomu, že mnohé spoločnosti neustále vyhodnocujú svoje riešenia PLM a zlepšujú zlepšenia. Rozhodnutie môže byť spôsobené uznaním, že súčasné riešenie, alebo častejšie, jeho údržba alebo použitie viacerých systémov, nie je spokojná s riadením spoločnosti. Okrem toho existuje ďalší spoločný motív - dôsledky akvizícií spoločnosti a uvedomenie si, že konsolidácia ich rôznych Riešenia PLM je odôvodnené. Ďalším scenárom je potreba masívnej rekonfigurácie súčasnej platformy. Bez ohľadu na príčiny zmien bude efektívne vykonávanie zmien závisieť od úspešnej migrácie existujúcich údajov na novú platformu.

Problémy s migráciou dát

Migrácia údajov robí mnohé otázky do popredia. Môže sa napríklad zistiť, že toto je prvý audit, ako spoločnosť zvolila nástroje na správu produktov. S cieľom prekonať zjavné nevýhody v súčasnom modeli dát, ktorý sa v priebehu času vyvinula, môže spoločnosť zmeniť časti modelu alebo ho rozšíriť. V každom prípade budú tieto zmeny mať dodatočný tlak na proces prechodu zo starého na nový, jednoduchý prenos dát nemusí byť možný. Jedným z najdôležitejších momentov migrácie je, že najprv musíte určiť všetky údaje, ktoré podliehajú zváženiu. Mnohí sa domnievajú, že hovoríme len o prevode digitálnych údajov, však skúsení špecialisti určite uznávajú, že určitá časť kritického IC spoločnosti môže byť stále v tlači, alebo vo všetkých jej nosičoch sú vedúcimi vedúcich zamestnancov.

Po zistení údajov, ktoré podlieha migrácii, je potrebné vyvinúť a vykonávať procesy kontroly ich správnosti. Údaje môžu byť často zastarané, pretože najnovšie zmeny neboli vykonané na skoršie verzie údajov. Okrem toho sa často používajú duplicitné údaje (alebo podporované v niekoľkých systémoch), ktoré vyžadujú konštantný alebo pravidelný test konzistencie a čistenia údajov. Určenie plnej výšky údajov pre migráciu si vyžaduje použitie znalostí najskúsenejších zamestnancov spoločnosti.

Možno jedným z najväčších problémov migrácie dát sú termíny pre migráciu. Staré údaje budú neustále dopĺňané a upravené, pretože spoločnosť nemôže zastaviť svoju prácu a čakať na ukončenie novej implementácie PLM. Okrem toho má migračný tím veľmi obmedzený technický čas na skutočné prepínanie, je to typicky víkendy alebo sviatky. Potreba splniť sa v cenovo dostupnom čase kalendára vyžaduje implementáciu migračných algoritmov pomocou špeciálnych nástrojov, pretože údaje môžu ľahko obsahovať stovky tisíc (alebo dokonca miliónov) záznamov.

Príklad riešenia

Zamerajme sa na skúsenosti tých, ktorí pravidelne realizovali a migrujú údaje PLM. Jeden z uznaných špecialistov v oblasti migrácie údajov PLM je nemecká spoločnosť Prion Group, ktorá má jedenásťročná skúsenosť s poskytovaním takýchto služieb a účinných nástrojov na ich implementáciu. Keďže portfólio PRIR zahŕňa rozhrania pre najbežnejšie PDM a zdedené systémy, z ktorých musia byť údaje prevedené, v každom prípade, spoločnosť nie je potrebné obnoviť softvér na migráciu. To vám umožní rýchlo rozvíjať plán prechodu, ktorý zohľadňuje charakteristiky konkrétnej spoločnosti a rýchlo vykonávať migráciu, aby sa minimalizoval jeho vplyv na vývoj a výrobu produktov. Nižšie uvedený obrázok zobrazuje diagram typického procesu migrácie údajov pre priónovú metodiku.

Najvýznamnejším je, že výkon tohto systému opakovane potvrdil projekty migrácie PLM Migrácia migrácie z mnohých klientov PRIR. Okrem toho sa preukázali opakované pokusy o výrobu priameho vysielania údajov z jedného systému PLM na druhú, 100% nefunkovateľnosti takéhoto primitívneho prístupu. Medzi faktory určujúce tento stav: zber údajov z niekoľkých zdrojov, potreba transformovať a vyčistiť údaje, ich certifikáciu a nakladanie do nového systému (systému), ktoré môžu byť tiež fyzicky distribuované. Pri prechode na novú platformu PLM je teda úplne neprijateľná.

Na zníženie týchto rizík sa prión vyvinula migračné nástroje, ktoré používajú medziproduktovú databázu. Údaje sa vyvážajú do medziľahlej databázy a pred stiahnutím na novú cieľovú platformu PLM sa konvertujú na túto databázu. Takýto prístup nevedie k okamžitej zmene pracovných údajov a podnikania môže pokračovať ako obvykle, zatiaľ čo pravidlá a podrobnosti o procese migrácie údajov sa vyvíjajú. Kritickým faktorom úspechu migrácie je vytvoriť systém riadenia zmien tak, aby nielen sledovať zmeny vykonané počas migrácie samotných údajov, ale aj zmeny údajov vykonaných po stiahnutí do novej platformy PLM. Tento systém riadenia zmien musí podporovať špecifické požiadavky zákazníka z samotného procesu migrácie pred spustením nového operačného systému v reálnych podmienkach.

Skutočnosť, že prión môže využiť mnohé z migračných scenárov z ich rozsiahlej knižnice, ktorá bola vyvinutá pre bývalých zákazníkov znižovať rizík migrácie a výrazne znižuje náklady pre budúcich zákazníkov. Tento prístup pomáha v mnohých ťažkých scenároch migrácie, najmä keď cieľový systém je distribuovaným riešením.

Viac informácií o priónových nástrojoch a službách odporúčam kontaktovať stránku.

Prenos dát je pohyb uložených digitálnych informácií medzi počítačmi, systémami alebo formátmi. Prenos dát sa vyskytuje z viacerých dôvodov, vrátane výmeny alebo údržby servera, meniacich sa dátových centier, projektov konsolidácie dát a aktualizácií systému. Keďže väčšina firemných znalostí a obchodných analytikov spoločnosti sú obsiahnuté vo svojich údajoch, každý projekt migrácie údajov musí byť starostlivo dokončený na minimalizáciu rizík.

Vykladanie "migrácie údajov"

Prenos dát je významným rizikom kontinuity podnikania, ak je nesprávne. Strata údajov, samozrejme, je to najhorší scenár, ale spoločnosti by sa mali zaoberať aj časom v oblasti nečinnosti, problémy s kompatibilitou a celkovým problémom s výkonom systému. Prenos dát je brzdený kvôli veľkému množstvu údajov, rôznych dátových formátov a rozdielov v údajoch v spoločnosti.

Aby sa minimalizovalo riziká migrácie údajov, spoločnosť vytvára podrobné politiky prenosu údajov, ktoré podľa potreby pozastavia zálohu, pohyb pohybu a paralelné dátové prostredie. Ak spoločnosť nemôže začať predbežné migračné prostredie pri príprave nového prostredia, potom bude významný čas nečinnosti, pretože obchodné operácie v aktuálnych aplikáciách sú pozastavené, aby umožnili migráciu údajov. Tento typ zastavenia, prenosu a štartovania sa môže vyžadovať pri prechode na nové platformy alebo v prítomnosti tvrdých obmedzení fyzického skladovania a pre existujúce skladovacie technológie sú potrebné swap alebo opravy.

Migrácia dát s nulovým prestojom

Migračný model s nulovým prestojom závisí od prítomnosti dostatočného počtu archív na vytvorenie a spustenie dvoch plných prostredí. Úplná kópia údajov spoločnosti je prevzatá do nového prostredia a je kontrolovaná, zatiaľ čo zamestnanci zostávajú v starom prostredí. Chyby sú vyvinuté z nového systému, čím sa zabezpečí, že všetky aplikácie stále fungujú, a všetko je tam, kde by mal byť. Po ukončení testovania sa objaví nová kópia a všetci zamestnanci idú do nového prostredia. Staré dátové prostredie je niekedy otvorené niekoľko mesiacov, aby zamestnanci mohli prijímať súbory zo starého dátového systému, ale na tieto servery nepísali nové údaje. Všetky migrácie dát sú vykonané na kontrolu údajov po migrácii na overenie straty dát.

Jedna vec, ktorá môže zlepšiť migráciu dát, je čistenie a štandardizácia dátových postupov na migráciu. Dátová organizácia spoločnosti je často odrazom rôznych zvykov pri podávaní svojich ľudí. Dvaja ľudia s rovnakou úlohou môžu používať úplne iné metódy. Napríklad zachovanie zmlúv na dodávateľa v jednom prípade, ako aj počas fiškálneho roka a mesiac v inom. Zjednotenie dátových metód môže byť oveľa dôležitejšou úlohou, než je skutočná migrácia údajov, ale čisté, koherentné organizované údaje, ktoré sú podporované jasnými politikami, pomáhajú budúcim dôkazom údajov o dátach spoločnosti pre mnohé migrácie stále dopredu.