Технологія проведення міграції даних в великих проектах. Міграція баз даних Методика міграції даних

як впровадити вільне ПЗ

Міграція на вільне ПЗ подібна міграції на новішу операційну систему. Як приклад, можна згадати появу перших варіантів Windows в нашій країні. Не менш яскравий приклад - міграція на Windows NT, ідеологія роботи в якій різко відрізнялася від Windows 9x. Можна навести ще один приклад - кожна нова версія пакету MS Office відрізняється від попередньої не тільки відмінностями в інтерфейсі, але і форматами файлів. Отже, завдання міграції є актуальною навіть в такому випадку, коли використовується ПО від єдиного виробника.

У даній статті пропонується загальний опис методики міграції з освітленням істотних моментів. Загальний принцип міграції складається вдумливого, обережному здійсненні процесу шляхом поступових змін. Міграція складається з декількох логічно цілісних ділянок, етапів.

створення робочої групи (хто робить)

При здійсненні міграції необхідно передбачити вирішення питань як технічного, так і нетехнического характеру.

Важливо розглянути правові проблеми, які останнім часом надзвичайно актуально стоять для деяких країн СНД, зокрема, України. У деяких випадках осмислено обговорити адміністративні завдання взаємин "роботодавець-користувач-адміністратор". Історично склалося, що ці відносини недостатньо регламентовані внутрішньокорпоративними правилами та інструкціями.

У процесі підготовки матеріалу були проведені бесіди з професіоналами в області безпеки, комп'ютерного права і системними адміністраторами. Переважна більшість заявляли про необхідність документального оформлення правил роботи користувачів з інформаційною системою організації.

Правильне планування також включає в себе вирішення фінансових питань. Необхідно провести оцінку витрат на легалізацію існуючої інформаційної системи, вартість впровадження нової, оцінити вартість володіння в доступному для огляду майбутньому.

Будь-який проект, в тому числі проект міграції, може зіткнутися з недооцінкою людського фактора. Природно, буде потрібно застосування методів управління людськими ресурсами. Більшість відомих автору системних адміністраторів та ІТ менеджерів не є фахівцями в областях управління персоналом або фінансів. Подібну комплексну задачу неможливо вирішити силами одного ІТ-департаменту.

Першим завданням на шляху до міграції на нову, цільову систему є створення робочої групи планування міграції. Дана група відповідальна за проведення міграції і, отже, повинна мати досить широкими повноваженнями.

Метою проекту є побудова економічно виправданою ІТ-інфраструктури. Хорошим кандидатом на посаду керівника робочої групи буде топ-менеджер підприємства або організації, наприклад - фінансовий директор. Природно, до цієї групи входить начальник ІТ-департаменту, який володіє баченням всієї ІТ-інфраструктури як на даний момент, так і в перспективі. У складі групи обов'язковий досвідчений системний адміністратор, бажано з досвідом експлуатації вільного ПЗ. Розмір групи неможливо оцінити - в деяких випадках залучаються при необхідності інші співробітники фірми. Можливе залучення стороннього консультанта з досвідом, або - що спеціалізується на подібних рішеннях фірми. Результатом роботи цієї групи є розгорнутий план міграції з оцінкою вартості міграції. Або - пояснення неефективності міграції на вільні рішення для організації.

дослідження (що є)

Першим етапом має бути аудит - опис існуючої (успадкованої) системи.

Не секрет, що, при роками яку застосовували "авральною" інформатизації без урахування окупності витрачених на ПО коштів результатом були, як правило, не тільки економічно, але і технологічно незбалансовані системи. Аудит програмного забезпечення підприємства являє собою ревізію встановлених програм, визначення відповідності їх вимогам бізнесу.

Результатом процесу аудиту є:

Опис технічних характеристик встановленого ПО;

Список виявлених ризиків, пов'язаних з використанням неліцензійного ПЗ;

Підрахунок вартості придбання ліцензій на встановлене ПЗ;

Підрахунок вартості видалення неліцензійного і установки ліцензійного ПЗ;

Визначення доцільності подальшого використання ПЗ;

Список виявлених ризиків, пов'язаних з використанням ПЗ;

інвентаризація ПО

Деякі дослідження показують, що більшість керівників організацій більшу увагу приділяють функціональності використовуваного ПО і набагато менше - дотримання прав на використовувані продукти.

На жаль, в більшості організацій відсутня ІТ-культура. Іноді навіть представники ІТ-служби толком не знають, що і де встановлено на комп'ютерах у працівників, а рядові співробітники самостійно вирішують і встановлюють програмні продукти, отримані з сумнівних джерел.

Інвентаризація ПО дозволяє виявити неліцензійне ПЗ в організації. Слід підкреслити, що даний захід завжди вигідно. Результатом інвентаризації можна скористатися для оцінки витрат на легалізацію ПЗ як з використанням вільного, так і з використанням невільного ПЗ.

Керівники організацій часто зацікавлені в чіткому фінансовому плануванні витрат на використання і розвиток програмного забезпечення. Зацікавленість топ-менеджерів в такий подібної деталізації цілком зрозуміла - топ-менеджмент компаній зацікавлений у перетворенні ПО на майно підприємств, який враховується, контролюється і розвивається аналогічно іншим видам активів.

Аудит ПО - процедура, що займає, як правило, досить багато часу, що вимагає на етапі аналізу інформації високої кваліфікації персоналу і знання різної специфічної інформації. Рекомендацією може бути звернення до спеціалізується на даних послугах фірму. Проте, цілком можливо провести аудит силами ІТ департаменту.

У деяких організаціях незручно (найчастіше - неможливо) проводити одноразово великомасштабну інвентаризацію ПО. Причинами можуть бути розміри організації або політика безпеки. Необхідно знайти компроміс між ефективністю інвентаризації та факторами, що ускладнюють подібний процес.

Можна розглянути два варіанти проведення аудиту. Перший варіант - повний аудит, про якому проводиться дослідження всіх обчислювальних засобів, локальної мережі та периферії. Гідність даного методу - висока точність, недолік - велика вартість, високі витрати часу і незручність для користувачів. Додатковими перевагами даного методу є можливість виявити самостійно встановлене користувачами ПЗ і вивчити вимоги користувачів до ПЗ на їх робочих місцях, використовуючи спеціально підготовлені анкети. Другий варіант - аудит деяких типових обчислювальних засобів, локальної мережі та периферії. При цьому вибір об'єктів аудиту диктується, як правило, функціональними обов'язками користувачів. Такий метод апроксимації значно здешевлює вартість інвентаризації, але володіє великою похибкою.

Невеликі організації можуть провести аудит вручну, і внести відомості про комп'ютери та серверах, а також про встановлений на них програмному забезпеченні, в електронну просту таблицю. При цьому слід вказати наявність або відсутність необхідних ліцензій, сертифікатів автентичності та авторських договором для кожного з знайденого програмного продукту.

Для середніх і великих можна рекомендувати використання спеціалізованого ПЗ або запросити сторонню організацію, що спеціалізується на подібних послугах. У процесі створення документа були проведені роботи по огляду засобів автоматичної інвентаризації програмного і апаратного забезпечення (відомі програми GASP, PC inventory, MSIA). Рекомендацією може стати eXponent Navigator (http://www.e-x.ru/pages/expnav.html), виробництва eXponent.

Exponent Navigator

Продукт призначений для ревізії обладнання і програмного забезпечення по мережі. Відомості про комп'ютерах містять у собі дані про комплектуючих (процесор, материнська плата, вінчестери, модулі пам'яті, відео-карта, мережеві карти, принтера та інші пристрої), операційну систему, драйвери і програмне забезпечення.

За твердженням творців програми, після організації автоматичного збору відомостей про комп'ютери є можливість переглядати і упорядковувати цю інформацію, готувати друковані звіти і веб-публікації, вивантажувати дані в Microsoft Excel, XML та інші формати. можливості:

Автоматична діагностика конфігурації комп'ютерів;

Автоматичний збір інформації про комп'ютери по мережі;

Визначення встановленого обладнання;

Визначення встановлених програм;

Визначення файлових характеристик;

Розширені можливості сортування, пошуку і відбору даних;

Підготовка друкованих звітів;

Експорт даних в MS Excel;

Автоматична генерація веб-публікацій.

В безкоштовному варіанті програми існує обмеження - облік до 25 комп'ютерів; вартість ліцензії становить $ 1 за 1 комп'ютер.

проектуємо (що хочемо)

Оброблені результати дослідження існуючої системи є підставою для моделювання нової, цільової системи. Це питання надзвичайно важливий і складний. Ускладнює розгляд даного питання і історично сформований недолік знайомства з вільним ПЗ, зокрема Linux, більшості ІТ менеджерів і системних адміністраторів.

Існує маса літератури, в тому числі російськомовної, про Linux, в якій описано перевага цієї платформи з технологічної точки зору. Однак, всі ці переваги мають значення разом з головним питанням - існуванням широкого спектру прикладного ПО різного спрямування. Досить давно і широко поширений міф про те, що під платформу Linux існує обмежена кількість прикладного програмного забезпечення для корпоративного користування, в тому числі офісної автоматизації. У переважній більшості ці міфи створюються і підживлюються творцями і продавцями пропрієтарного програмного забезпечення і мають мало спільного з дійсністю. Розвінчання даного міфу не є головною метою даної книги. Проте, варто зауважити, що, наприклад, широта прикладного ПО є абсолютним фантомом з урахуванням сформованих історично стандартів на обмін документів. Так, наприклад, фактичним стандартом офісного редактора є Microsoft Office, редактором растрової графіки - Adobe Photosop, а в якості векторної графіки надзвичайно поширений Corel Draw.

Ще одним питанням є, найчастіше, надлишкова функціональність пропрієтарних продуктів, продиктовані не потребами ринку, а думкою маркетологів. І за цю надлишкову функціональність користувач виплачує чималі гроші: вартість ліцензії на право використання програм, що підвищується складність експлуатації та підвищені вимоги до апаратного забезпечення.

Останнім часом ситуація змінюється - з'являється маса інформації, присвяченій прикладного застосування Linux. Ймовірно, найкращим матеріалом буде даний документ :-), в якому планується висвітлити безліч адміністративних і технічних питань.

Однак, в даний момент документ тільки створюється і інформацію можна знайти в різних джерелах. Неможливо пройти повз матеріалів Valery V. Kachurov, несов Артем "Аналоги Windows-програм в Linux - таблиця відповідностей." (Http://linuxshop.ru/linuxbegin/win-lin-soft/). Цей ресурс містить масу цінної інформації. На жаль автори, здається, закинули цю працю. Даний розділ сайту регулярно недоступний, але копію таблиці можна знайти за адресою http://www.blif.net/modules.php?name\u003dLinWin. Можна порадити ресурси Open Source Applications Foundation
(Http://www.osafoundation.org/), особливо http://www.osafoundation.org/desktop-linux-overview.pdf.

Результатом є:

Створення прототипу робочих станцій;

Підрахунок вартості ліцензій на пропоноване ПО;

Навчання користувачів;

Створення зразкового календарного плану впровадження;

Список ризиків при впровадженні вільного ПЗ;

Підтримки вільних рішень;

Підрахунок економічної ефективності нової системи на термін до п'яти років.

пілотний проект (перевірка боєм)

Через великої кількості факторів в успадкованої системі, великого числа користувачів, на яких потенційно впливає міграція, рекомендується експериментальне виконання міграції в маленькому масштабі - пілотний проект. Цей етап необхідний для перевірки та коригування планів міграції і прототипу нової системи. Саме пілотний проект є основою для прийняття рішення про впровадження нової інформаційної системи на базі СПО. Другою цінністю пілотного проекту є можливість інформувати користувачів про нову систему, отримати зворотній зв'язок з користувачами. Третім аргументом на користь пілотного проекту буде можливість експериментальним шляхом визначити більш точно вартість проекту.

При виборі об'єкта випробувань необхідно знайти золотою середину. По-перше, вибраний об'єкт повинен надати достовірні дані для оцінки. По-друге, проведення пілотного проекту не повинно надавати критичний вплив на ведення бізнесу.

На даному етапі також проводиться навчання системних адміністраторів і кінцевих користувачів: надаються прототип методичних матеріалів, документація, ресурси в мережі Інтернет. Рекомендується користувачів, які беруть участь в пілотному проекті «розвантажити» і дати можливість частину часу використовувати на освоєння нової системи.

Експериментальний етап особливо затребуваний:

Якщо не була доведена можливість міграції користувачів від успадкованої системи до нової системи;

Якщо є призначений для користувача скептицизм, який буде здатний загальмувати процес міграції;

Організація відчуває нестачу корпоративної культури (що, на жаль поширене на території СНД);

Якщо є обмежені ресурси для великомасштабної міграції;

Організація велика, і в експериментальний проект не залучено багато користувачів;

Якщо успадковані пропрієтарні системи стрімко еволюціонували як в - технічному плані, так і в зниженні вартості;

Чи не з'ясований повністю економічний ефект міграції.

Щоб досягти успіху, пілотний проект:

Чи не повинен ставитися до критичного ділянці бізнесу;

Повинен бути досить важливий для бізнесу;

Чи не повинен вимагати черезмерного ресурсу людей, які вже обмежені в часі;

Повинен мати істотну групу підтримки;

Повинна бути забезпечена зворотний зв'язок з користувачами (системи Help Desk);

Чи не повинен бути в сфері інших обмежений (наприклад, важливий для бізнесу період).

Залежно від величини організації, можливі одна або більше експериментальних стадій, що дозволяють точніше визначити рядки і вартість міграції на вільне. Важливо оцінити його результати і визначати, чи є бачення і цілі практичними або вони повинні бути змінені або можливо навіть залишені. Дані від цих пілотних проектів повинні бути використані для коригування планів і підрахунку остаточно вартості. В процесі експерименту необхідно уточнити питання:

Опис прототипу робочих станцій;

Опис специфічних налаштувань користувача:

Середні витрати на розгортання типів станцій;

Перенесення даних з успадкованою системи в нову;

Навчання користувачів;

Підрахунок вартості впровадження ПО;

Підтримки вільних рішень.

планування (що і як)

1. Створення плану міграції. План міграції повинен відповідати на питання:

Опис фаз побудови системи;

Визначення потреб підтримки;

Опис завершення міграції.

Фактично, проводиться остаточний вибір, як буде відбуватися міграція. Стверджується кошторис витрат на міграцію.

2. Опис фаз побудови системи. Повинна бути зроблена оцінка фаз побудови системи, які найкраще підтримують пріоритети користувальницьких потреби.

План повинен відповідати на наступний питань:

Якою мірою і якими етапами система повинна бути встановлена \u200b\u200bі розгорнута, щоб максимально задовольняти потреби користувачів?

Що необхідно для кожної фази міграції на нову систему від клієнтів організації і користувачів системи?

Яке буде вплив і ризик використання системи на кожному етапі збільшення?

Етапи розгортання системи повинні бути чітко позначені в плані мигрирования; клієнти, розробники, і користувачі повинні бути ознайомлені. Оцінки ризиків повинні бути виконані перед завершенням плану побудови системи. Необхідно переконатися, що оцінки планування розумні, підхід добре задуманий відповідно до пріоритетів організації, і потенційний вплив на клієнтів і користувачів прийнятно.

3. Визначення потреб підтримки. Потрібно забезпечити оптимальний рівень підтримки, щоб допомогти користувачам у використанні нової системи. Крім того, користувачі часто вимагають, щоб служба підтримки допомогла їм зрозуміти загальні здібності (можливості) цільової системи.

Питання, які необхідно вирішити, включають:

Якого навчання і допомоги в експлуатації користувачі будуть вимагати?

Який загальний рівень підтримки міграції, яка буде вимагатися користувачам, щоб гарантувати успішну міграцію?

Як досягти прийняття цільової системи користувачами і уникнути опору користувачів впровадженню нової системи?

Яким чином будуть повідомлятися клієнтам і користувачам неминучі зміни в особливостях систем і послугах?

Чи можлива підтримка вільного рішення ІТ підрозділом організації або кращим варіантом буде аутсорсинг?

План міграції повинен зосередитися на вирішенні цих питань, плануючи підтримку користувачів в областях:

Система повідомлення неприємностей;

Служби технічної допомоги для нових систем;

Технічна допомога користувачам, мігруючих до нових системи;

Керівництва користувачів на перехідній і наступний періоди;

Навчання для користувачів у вивченні і пристосування до нової системи, до виконання тих же самих типів завдань;

Можливість випробування використання нових систем;

Демонстрацій використання нових систем, щоб показати існуючим користувачам успадкованих систем, як нова система працює і як вони можуть виконувати порівнянні завдання;

Подолання поточних експлуатаційних проблем.

На етапі навчання користувачів приділіть особливу увагу тим, хто є прихильником старої системи і / або противником нових систем.

4. Опис завершення міграції. Після закінчення кожної нової фази розгортання і навчання, розробники і впроваджувачі повинні гарантувати, що користувачі максимально комфортно мігрують до нової цільової системі. План міграції повинен передбачити, щоб прискорити зусилля міграції і до видалення успадкованої системи як тільки можливо.

Необхідно передбачити додаткове зусилля, яке може бути необхідно для "останніх адептів" та інших користувачів, хто відчувають непередбачені проблеми. Інший аспект цієї діяльності оцінює час і вартість, щоб закінчити перехід всіх користувачів до нової системи і до видалити старі системи, побудовані на неліцензійному пропрієтарного ПЗ.

Керівництво організації, розробники і впроваджувачі повинні розглянути включення декількох підходів, щоб допомагати мігрувати користувачам успадкованих систем:

Повідомляти кожній групі користувачів, як і коли вони повинні здійснювати перенесення своїх завдань на нові системи, яким чином змінюється робоче навантаження на період міграції з успадкованих систем;

Встановити стимули до дій повністю перейти на нову вільну систему і усунути залежності від успадкованих систем;

Передбачити допомогу (програмне забезпечення і додатковий персонал) для перетворення успадкованих даних в нову систему; - порядок виведення з експлуатації успадкованих систем;

Архівування даних успадкованих систем і їх зберігання.

міграція (робимо)

Все, що залишається на останньому етапі - працювати згідно з планом.

Активно керуйте і контролюйте процеси міграції:

Встановіть критерії вимірювання і відстежуйте етапи міграції та витрати ресурсів на міграцію;

Робіть періодичні огляди ситуації і ознакомлівайте з ними, відповідно до повноважень та організаційної політикою, зацікавлених людей (керівництво, менеджерів проектів і спонсором);

Встановлюйте систему відстеження (tracking), щоб управляти просуванням процесів (прогресом), проблемами, рішеннями, і іншими діловими питаннями, які відносяться до планування міграції і виконання планів.

Вадим Машков, UA-FOSS, [Email protected]

У даній статті ми хотіли б систематизувати наш досвід проведення міграції даних в великих корпоративних проектах, пов'язаних з переходом Замовників на роботу в конфігураціях «1С: Підприємство 8».

При цьому основний акцент в статті буде зроблений, перш за все, на технологічну складову процесу міграції. Організаційна складова також порушена, але в меншому ступені.

терміни та визначення

Під міграцією даних прийнято розуміти кінцеву послідовність робіт, проект, спрямований на разове масове переміщення даних з систем-джерел (історичні системи) в систему-приймач. При цьому експлуатація цих даних в системах-джерелах припиняється.

Слід відрізняти міграцію даних від інтеграції даних. Інтеграція, на відміну від міграції - це постійна частина архітектури IT, і відповідальна за потоки даних між різними системами і сховищами даних - і є процесом, а не діяльністю по здійсненню проекту.

Схема міграції в загальному випадку виглядає наступним чином:

Мал. 1

історичні системи - бази даних компанії Замовника, які планується повністю або частково замінити при впровадженні нової системи.

Система-приймач - цільова система, довільна конфігурація «1С: Підприємство 8».

Початкові дані - дані, вивантажені з історичних систем в довільний формат xls-файлів. В даному випадку формат xls представляється, як один з найбільш зручних, оскільки можливість вивантаження в xls-файл присутній в багатьох облікових системах «попередніх поколінь».

Як сучасну альтернативу в якості транспорту можливо розглядати формат xml-файлів.

Також існують варіанти використання проміжної бази даних.

Трансформація, конвертація - процес перетворення вихідних даних в дані для завантаження. Трансформація даних відбувається відповідно до шаблонами для завантаження. Результатом трансформації є дані для завантаження.

Дані для завантаження - дані, призначені для завантаження в систему-приймач. У даній статті, так само як і вихідні дані, розглядається xls-формат.

Шаблони даних для завантаження - опис таблиць даних для завантаження в цільову систему.

етапи міграції

Розглянемо поетапно процес підготовки і проведення міграції.

До організаційних етапах міграції можна віднести наступні пункти:

· Визначення стратегії міграції. На даному етапі Виконавець і Замовник домовляються про технології проведення міграційних робіт;

· Визначення складу робочої групи з міграції. До робочої групи повинні входити фахівці і Виконавця і Замовника, знайомі в достатній мірі з роботою історичних систем (з боку Замовника) і цільової системи (з боку Виконавця);

· Попередній план міграції. План міграції по ходу проекту буде неодноразово коригуватися;

· Періоди дат вивантаження даних з історичних систем, обсяги даних. Періоди зрізу даних для міграцій, дати тестових і підсумкової міграцій. Дану інформацію можна віднести до плану міграції;

· Склад даних, що підлягають міграції. Довідкові дані, класифікатори, транзакційні дані, залишки, обороти і ін .;

· Питання перевірки якості, коректності та цілісності даних в процесі міграції і за підсумками;

· Питання відкату до попереднього стану в разі збоїв.

Зупинимося докладніше на технологічних етапах міграції.

Мал. 2

1. Підготовка шаблонів завантаження даних

Шаблон завантаження даних містить технічні описи таблиць даних для завантаження, алгоритми і правила завантаження для поточного шаблону.

Кожен шаблон в загальному випадку призначений для однієї або декількох пов'язаних таблиць в цільовій системі-приймачі.

У шаблоні вказується:

· Опис усіх полів xls-файлу даних для завантаження, включаючи:

o Ім'я поля

o Ознака обов'язковості заповнення поля

o Приклад заповнення поля

o Примітка

· Опис правил завантаження таблиці цільової системи на підставі даних для завантаження (черговість в разі декількох пов'язаних таблиць, алгоритми пошуку по ключових полях і т.п.)

· Опис заповнення безпосередньо полів таблиць цільової системи в разі, якщо передбачається щось відмінне від перенесення даних «один в один» з файлу даних для завантаження. Актуально для посилальних полів, наприклад.

В процесі робіт по даному етапу Виконавець також повинен підготувати завантажувач файлів даних для завантаження. У разі роботи з файлами xls дана задача не представляє особливої \u200b\u200bскладності.

2.Виявлення джерел даних

Даний етап може починатися разом з попереднім етапом «1. Підготовка шаблонів завантаження даних ».

В рамках даного етапу фахівці Замовника визначають з яких систем і які дані можуть бути вивантажені. Також слід визначити які дані можливо можуть знадобитися.

Як правило, у великих проектах міграції виявлення повного вичерпного переліку джерел даних може займати досить тривалий час і відбувається в міру робіт на подальших етапах.

Нерідкі ситуації, коли для забезпечення в подальшому цілісності інформації деякі дані доводиться переносити з друкованих джерел (оцифровувати) або навіть заносити в таблиці зі слів ключових співробітників Замовника.

Проте, на даному етапі потрібно постаратися виявити якомога більше необхідних даних.

3.Вигрузка вихідних даних

Процес вивантаження даних з історичних систем може зайняти достатню кількість часу, особливо, якщо систем багато, вони різні і за них відповідальні різні підрозділи Замовника. Необхідно враховувати даний момент при тестових і підсумкової міграціях.

Найбільш зручним варіантом представляється вивантаження в xls файли. Багато старих IT-системи підтримують такий варіант.

Також можуть бути варіанти вивантаження в csv формат, dbf, xml формати і інші.

Варто відзначити, що з тих чи інших причин (питання безпеки, наприклад) Замовник не завжди може надати вивантаження даних в повному обсязі на цьому етапі! Тільки структура даних і кілька тестових позицій. Таким чином, може скластися така ситуація, що при тестових і підсумкової загрузках будуть виявлятися неякісні дані у вихідних таблицях, що буде призводити до незапланованих помилок.

Для мінімізації даної проблеми слід обумовити заздалегідь обсяги тестових вивантажень з історичних систем.

4.Меппінг даних

Меппінг (data mapping) - в загальному випадку процес зіставлення даних історичних систем і системи-приймача. Тобто, вихідних даних і даних для завантаження.

Етап меппінга - найбільш трудомісткий етап і може займати більше 50% всіх робіт по завданню міграції.

На даному етапі в повній мірі задіюється вся робоча група проекту з міграції.

В процесі меппінга даних необхідно виділити підетапи меппінга таблиць і меппінга полів.

· Меппінг таблиць, або меппінг шаблонів - зіставлення таблиць вихідних даних і шаблонів даних для завантаження. Відповідність може бути як 1: 1, так і N: N. В результаті даної роботи складається і підтримується реєстр меппінга таблиць. Даний підетапів необхідний для наступного підетапи меппінга полів і для відстеження загального стану справ по меппінга.

Група шаблонів 1С

Найменування шаблону 1С

Найменування файлу-

джерела

Правила формування файлу-джерела

відповідальний

статус

Примітка

НДІ

Шаблон_

номенклатура

номенк

латура.xls

В системі N встановити відбір
. Зберегти в txt
. Відкрити в xls, колонки - текстові
. Перший рядок - шапка
. Кількість стовпців - 15
. Звірити кількість рядків в txt і xls
. Найменування листа завжди "Лист1"

Іванов І.І.

в роботі

· Меппінг полів - зіставлення полів таблиць в рамках вже певного меппінга таблиць. Результатом даної роботи є реєстр меппінга полів.

№пп

Кл. поле

обов'язковий

Ім'я поля шаблону 1С «Шаблон_Номенклатура»

опис

Ім'я поля «Номенклатура.xls»

алгоритм заповнення

код

Код елемента довідника

код

Найменування

Так

Це група

Містить одне із значень:
. 1 - для груп
. 0 - для елементів

Якщо довжина коду \u003d 11 символів і останні 4 символи<> "0000", то це елемент - "0", інакше група - "1".

Повне найменування

Найменування елемента довідника

Найменування

Якщо ЕтоГруппа \u003d 1, то "", ІначеЕслі ЕтоГруппа \u003d 0, то Найменування.

В рамках даного етапу також слід провести можливі роботи по нормалізації даних.

5.Подготовка правил трансформації

На відміну від попередніх етапів, даний етап - технічний і передбачає роботу розробника Виконавця.

На підставі узгоджених реєстрів меппінга полів фахівці Виконавця розробляють правила трансформації даних.

Для оперативної роботи в процесі підготовчих міграційних етапів і далі, в ході тестових і підсумкових міграцій важливо, щоб існувала зручне середовище розробки правил (скриптів) трансформації даних і середовище конвертації вихідних даних в дані для завантаження.

При цьому вимоги до даного середовища включають в себе:

· Зручність і швидкість розробки правил трансформації;

· Швидкість конвертації даних. Файли на вході і на виході можуть бути і в сотні тисяч рядків!

· Можливість працювати з декількома вхідними файлами одночасно;

· Можливість збереження правил трансформації в окремі файли.

Для своїх проектів міграції ми розробили спеціалізоване АРМ розробника, взявши за основу стандартну обробку «Консоль запитів» 1С.

Обробка «Консоль запитів» була доопрацьована для можливості робити прямі запити до файлів xls.

Наведемо приклад об'єднання двох вихідних xls-файлів Співробітники.xls

код співробітника	Прізвище	ім'я	По батькові	дата народження
2423	Іванов	Іван	Іванович	17.11.1992
1523	Петров	Василь	Олександрович	04.02.1991
4363	Сидоров	Кирило	Миколайович	01.05.1995
	Денисов	Денис	Денисович	01.01.1990

і Операції.xlsзі сторінками:

списання

код співробітника	Дата	сума
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

і надходження:

код співробітника	Дата	сума
	01.05.2004
	02.05.2004
	03.05.2004
	04.05.2004







2423дата народження	сума надходження	сума списання
Іванов Іван Іванович	2423	17.11.1992	1341234	1010
Петров Василь Олександрович	1523	04.02.1991	245245
Денисов Денис Денисович		01.01.1990	380000	320000
Сидоров Кирило Миколайович	4363	01.05.1995	613382	26336
РАЗОМ:			2579861	347842

Відзначимо, що приклад є штучним, спеціально підібраним для демонстрації всіх можливих стадій трансформації джерел даних.

Технологічна послідовність операцій трансформації тут виглядає наступним чином:

За допомогою мови запитів Access SQL (що дає істотні додаткові можливості, в порівнянні з цих слів 1С) створюється первинний запит, який видобуває дані з файлу xls в середу 1С. При цьому вже на даному етапі можливі різні перевірки і нормалізації даних.

Технологія доступу до даних ADO забезпечує високу швидкість роботи.

Мал. 3

2.Запрос на мові 1С - основний запит, який реалізує алгоритм меппінга полів. А також: збагачення даних при завантаженні даними з бази 1С, перегруповування, об'єднання з результатами запитів до інших вихідним xls-файл та ін.

3.Постобработка результату запиту 1С при необхідності. Реалізується за допомогою скрипта на мові 1С.

Для прикладу тут реалізується додавання рядка «РАЗОМ» по колонках сум.

4.Запісь підсумкового набору даних в xls-файл.

У загальному випадку на виході ми отримуємо підсумкові файли для завантаження в цільову базу даних 1С.

Також даний інструмент дозволяє зберігати правила конвертації даних в окремий xml файл:

Крім того, реалізована можливість працювати в пакетному режимі, Що особливо актуально при великій кількості різнорідних мігруючих даних.

В ході попередніх етапів підготовча частина роботи в цілому закінчується - виявлені всі джерела даних, зроблено вивантаження вихідних даних з джерел, підготовлені шаблони завантаження в цільову базу, підготовлений меппінг даних і, нарешті, розроблені скрипти трансформації даних.

Слід зазначити, що перед підсумкової міграцією обов'язково слід провести декілька тестових. В ході тестових міграцій Виконавець спільно з Замовників виявляють:

· Помилки конвертації, помилки завантаження даних

· Проводять попередню оцінку якості завантажуються в цільову систему даних

· За підсумками тестових міграцій складають / актуалізують план підсумкової міграції

7.Виверка даних

Перевірка якості завантажених даних повинна проводитися як після тестових міграцій, так і по закінченню підсумкової міграції. В ході вивірки можуть перевірятися наступні показники:

· Збіги підсумкових сум по залишкам, за документами;

· Кількісні збіги, наприклад кількість ОС;

· Коректність заповнення окремих вибіркових сутностей;

Звертаємо увагу, що ті чи інші перевірки мігруючих даних, питання нормалізації даних необхідно вирішувати на протязі всіх міграційних процесів. Необхідно завжди шукати відповіді на запитання, що потрібно зробити на поточному етапі, щоб уникнути помилок на наступних етапах.

наприклад:

· Перевірка на дублі по ключових полях. Можна і потрібно проводити ще на вихідних даних;

· Приведення типів полів;

· Посилальна цілісність;

· Математичні нестиковки. Наприклад, перевірка на незаповнені чисельні поля, на які заплановано поділ при трансформації;

· В цілому, перевірки обов'язкової заповнювання полів;

· Заміна некоректних символів. Наприклад, англійські символи в кириличних полях ( «о», «а», «е» і т.п.) Особливо актуально це для ключових полів!

· Перевірка значень строкових полів на відповідність типів системи-приймача (Обмеження по довжині)

Після завершення підсумкової міграції відповідно до заздалегідь визначеної стратегії міграції та плану міграції приймається рішення про подальшу експлуатацію історичних систем.

Часто експлуатація завершується відразу після фінальних звірок даних і фіксування успішності проведеної міграції - користувачі нової системи вже не ведуть облік паралельно в двох системах, а повністю переходять в нову систему. При цьому доступ до старої системи зберігається в режимі читання.

У деяких випадках може відбуватися паралельна робота двох систем на час дослідної експлуатації (ОЕ) і навіть більше цього періоду. Питання паралельної роботи користувачів в двох системах тісно пов'язаний з питанням можливості відкату до старої системи, в разі якщо міграція (або ж, в цілому, робота нової системи!) Буде визнана незадовільною.

висновок

У висновку хотілося б відзначити, що коли мова йде про міграцію великих транзакційних систем, до яких відносяться і багато конфігурації «1С: Підприємства», перехід на нову систему може бути вельми трудомістким.

Тому слід пам'ятати, що будь-який подібний проект вимагає ретельної підготовки і повинен супроводжуватися індивідуальним планом. Однак незалежно від типу мігріруемих систем, обсягів баз даних та ін. Загальна схема міграції виглядає практично ідентично.

Лейф Поулсен для InTech

Системи автоматизації виробництва і збору інформації про виробничі процеси живуть порівняно недовго. Їх часто доводиться модернізувати або замінювати до того, як процессное обладнання досягає кінця свого терміну експлуатації. Для багатьох компаній управління заміною чи модернізацією таких систем автоматизації без зупинки виробництва перетворюється на справжній виклик. Тому, об'єктивна необхідність в модернізації або заміні ігнорується до тих пір, поки що-небудь не відбудеться. Дана стаття присвячена тому, як можна успішно вирішити цю задачу, завдяки ретельно планування і організації.

Два основні чинники стоять за необхідністю модернізувати і замінювати системи промислової автоматизації та промислові ІТ-системи: технічна деградація цих систем, а також, зміни у вимогах бізнес-процесів, які цими системами підтримуються.

Надійність технічних систем буде зменшуватися з плином часу, якщо компанії ігнорують необхідність модернізації операційних систем, баз даних, ПО додатків. Операційний ризик відмови обладнання підвищується відповідно.

Завдяки ретельному плануванню, операційний ризик може утримуватися на прийнятному рівні, крім того, забезпечується захист інвестицій і мінімізуються витрати протягом життєвого циклу систем. Для типової системи автоматизації або ІТ, лише 20-40% інвестицій припадає на придбання системи. Решта 60-80% йдуть на підтримку її високої доступності та адаптацію до періодично мінливих вимог.

Крім оцінки активностей, необхідних для запобігання технічної деградації, необхідно враховувати нові виклики, а також потенційні бізнес-можливості. Бізнес-середовище постійно змінюється, і всі можливості поліпшення існуючих або впровадження нових технологій завжди необхідно враховувати. Типові бізнес-можливості, які можуть стати стимулами для міграції недешевих систем автоматизації - швидкість виведення нової продукції на ринок, конкурентоспроможність, зростання, якість і відповідність регуляторним вимогам.

План довгостроковій міграції

Розробка довгострокового плану міграції систем дозволяє компаніям підтримувати системні операційні ризики на прийнятному рівні. Крім того, він забезпечує управління ризиками та своєчасну підтримку бізнес-цілей. План міграції обов'язково повинен враховувати такі обмеження, як «кращі виробничі практики», функціональність технологій, неминучі простої виробництва.

Загалом, підхід до довгострокового планування зображений на рис.1. План міграції розробляється для того, щоб визначити, де компанія хоче бути через п'ять років, які необхідно для цього зробити дії і чи є потрібні для цього ресурси. Цей підхід базується на принципах архітектурного дизайну, викладених в стандарті TOGAF, який широко застосовується при розробці системної архітектури промислових підприємств.

Рис 1. Загальний підхід до створення довгострокового плану міграції.

Необхідно розрізняти існуючу архітектуру і цільову, бажану. Різниця між ними відображає різницю між становищем компанії в даний час і тим становищем, яке вона хоче зайняти в майбутньому. План міграції прокладає шлях від існуючої архітектури до цільової - можливо, через кілька перехідних етапів.

Кожна архітектура може бути описана як ряд «шарів», службовців сполучною ланкою між бізнесом і технологією - як показано на рис. 1. Увага необхідно приділяти таким «верствам»:

Бізнес-цілі це частина загальної роботи з планування стратегії. Вони дозволяють вибрати правильний напрямок процесу.
Бізнес модель забезпечує контекст, в якому розуміються виробничі та бізнес-процеси. Як правило, вона включає високорівневе опис потоків матеріалів і процесів.
опис виробничих і бізнес-процесів важливо для успішного застосування технологій і правильної оцінки їх цінності з точки зору бізнесу.
Інформація, дані та документи важливі для зв'язку процесів і додатків. Особливо важливі взаємодія і управління інформаційними потоками між додатками.
описи додатківдозволяють сформулювати високорівневі вимоги і визначити інтерфейси.
визначення інфраструктурних, обчислювальних і мережних вимог (апаратне забезпечення, відмовостійкість, продуктивність).
Надані послуги визначають вимоги щодо забезпечення ефективного операційного управління та підтримки рішень.

Розробка плану міграції

Розробка плану міграції для цілої організації, або навіть для окремої виробничої площадки, може бути по-справжньому складним завданням, що залучає безліч людей. Рекомендується розділяти процес розробки на кілька етапів, описаних нижче.

частина II

Етап 1: Мобілізація

Головні цілі:

досягти загального розуміння завдань і цілей
мобілізувати організацію, в якій планується проект
деталізувати план, описавши віхи і результати фаз проекту
зібрати всю необхідну / наявну інформацію
забезпечити належне розуміння концепцій, практик і теорії

планові зустрічі
робочий семінар, присвячений початку проекту

результати:

детальний консультаційний план
спільні цілі
огляд процесу

Етап 2: Аналіз

Метою етапу аналізу є:

аналіз бізнес- і виробничих процесів для того, щоб:

Оцінити готовність персоналу, що обслуговує системи ІТ і автоматизації

З'ясувати потреби в даних і функціональності для майбутньої архітектури

Визначити ключові переваги майбутньої архітектури для постановки цілей і здійснення економічного обґрунтування

аналіз існуючої архітектури

Визначення існуючих виробничих процесів в їх зв'язку з системами автоматизації, збором даних, системами управління виробництвом

Визначення існуючих бізнес-процесів і їх зв'язків з системами автоматизації виробництва

Визначення існуючих додатків, даних, логічної та фізичної інфраструктури, а також послуг технічної підтримки

Під час цього етапу здійснюються наступні активності:

семінари і дискусії, присвячені різним процесам
візити на підприємство для отримання контекстної інформації
семінари і дискусії, присвячені існуючим системам
оцінка сервісів для визначення ступеня їх зрілості і відповідності регуляційних вимогам

результати:

визначення існуючої інфраструктури
документація з аналізу
список ідей по викликів і можливостей нової архітектури список ідей по викликів і можливостей нової архітектури

Етап 3: Мета

Метою цього етапу є визначення та опис потреб, сформульованих на етапі аналізу.

Рішення, чи цільова архітектура буде описувати:

майбутні бізнес-процеси і функціональність
цільові типи додатків, з їх функціональностями, користувачами, інформацією і інтерфейсами
потреби в інфраструктурі та переглянуті стандарти підтримки

Під час цього етапу здійснюються наступні активності:

семінари та обговорення, присвячені покращенню процесів
семінари та обговорення, присвячені покращенню архітектури

результати:

майбутня архітектура (презентація)
короткий опис типів додатків

Етап 4: Обгрунтування

Метою етапу обґрунтування є первинне економічне обґрунтування, засноване на приблизних оцінках витрат і одержуваних в ході проекту переваг.

Розрив між існуючим і бажаним станом, як правило, веде до появи ряду ідей. Обгрунтування ідей дозволить відрізнити «необхідне» від «бажаного», і, після цього уявити і розвинути ідеї перед топ-менеджментом.

Під час цього етапу здійснюються наступні активності:

приблизна оцінка витрат і одержуваних переваг
перша версія презентації

результати:

спільні цілі
пріоретізаціі бізнес-ідей
оцінка необхідних ресурсів

Етап 5: План

Метою цього етапу є планування проекту на основі пріоритетів, ресурсів і залежностей:

планування послідовності реалізації етапів консолідованого проекту
забезпечення ресурсів і компетенцій, необхідних для наступних етапів
ініціація активностей з управління проектом
завершення консалтингу і передача результатів усіх етапів замовнику

Під час цього етапу здійснюються наступні активності:

розробка плану по впровадженню
розробка інвестиційного плану
оцінка ризиків

результати:

план по впровадженню
оцінка навантаження на персонал, задіяний в проекті
оцінка ризиків проекту
інвестиційний план (в першому наближенні)
фінальна версія презентації проекту

практичний приклад

Наступний приклад ілюструє застосування описаного підходу в реальних умовах. Для дотримання умов конфіденційності, в описі дотримується анонімність. Йдеться про досить великому підприємстві, яке виробляє активні компоненти для фармацевтичної продукції. Виробничі потужності були введені в експлуатацію понад 20 років тому, і, хоча з тих пір проводилася певна модернізація, цілий ряд застарілих систем вимагає заміни. Системи автоматизації будівель і РСУ - в першу чергу, так як вони засновані на застарілих технологіях, які складно підтримувати. Крім того, виробництво має адаптуватися до нових бізнес-вимогам, включаючи припинення виробництва одних продуктів і запуск інших. Загалом, є необхідність в роботі над планом міграції, що охоплює як технічні, так і бізнес-вимоги.

По-перше, необхідно створити загальний список устаткування, яке в даний час використовується по всьому підприємству. Ця інформація часто «захована» в різних документах (і пам'яті співробітників). Її треба витягти і візуалізувати, з тим, щоб вона стала основою планування міграції. З цією метою ми, як правило, створюємо діаграму процесних модулів, що показує основне обладнання і переміщення сировини і матеріалів в кожному виробничому підрозділі. В якості окремих шарів «поверх» обладнання, ми показуємо, які системи підтримують яке обладнання.

Приклад показаний на рис. 2. Дані про встановлені системах, також, містяться в системному сховище (або просто в Excel-файлах), і їх можна використовувати для подальшого аналізу і планування.

Рис 2. «Шар» автоматизації дозволяє оцінити існуючі систем

Перед обговоренням плану міграції, необхідно визначити основні бізнес-мотиви змін на виробництві. В даному випадку, керівництво виділило такі мотиви:

1. Неухильне і безпомилкове відповідність регулятивним вимогам

2. Мінімальні витрати часу для виходу на ринок, гнучкість

3. Успішність, конкурентоспроможність, операційне досконалість

4. Безкомпромісна якість

5. Зростання обсягів виробництва

Дані цілі необхідно перетворити в більш конкретні завдання, виконання яких може бути кількісно оцінений.

Потім, ми повинні з'ясувати, наскільки добре існуючі системи підтримують поточні і майбутні бізнес-процеси. Для цього ми використовуємо стандартну референсну модель (засновану на серії стандартів ANSI / ISA-95). Вона включає 19 високорівневих бізнес-процесів, деталізованих в тій мірі, яка дозволяє побачити слабкі місця в їх практичній реалізації і необхідність у змінах заради ефективного бізнесу.

Крім того, нам, також, необхідно оцінювати технічні можливості існуючих систем для підтримки бізнес-процесів в майбутньому. Це здійснюється систематично, за допомогою вищеописаної інформації з системного сховища. Для кожної системи, інформація про яку є в сховищі (в нашому випадку це близько 70 систем), необхідно оцінити наступні аспекти:

Стан обладнання (історія відмов, середній час напрацювання на відмову, вік обладнання, доступність запчастин)
Стан ПО (підтримка вендорів, наявність документації, персонал з необхідними компетенціями)
Можливості відновлення систем (резервування, середній термін служби до ремонту)
Оцінка впливу на бізнес (надання інформації, помилки даних, недоступність)
Індикативні показники (надійність системи, критична важливість системи і ін.)

Технічна оцінка виявила необхідність в модернізації і заміни ряду систем:

АСУ ТП грунтуються на звичайній, застарілої РСУ і безлічі різних ПЛК, ряд з яких вже «дозрів» для заміни.
Система автоматизації будівлі грунтується на більш новій платформі, але, також потребує модернізації для відповідності новим вимогам.
Ряд другорядних систем також вимагає модернізації, а то і заміни.
Інфраструктура, яка обслуговує всі системи, вимагає кращої сегментації і захисту для відповідності сучасним вимогам безпеки.

частина III

Після аналізу бізнес-цілей, намічених на майбутнє, стало очевидно, що жодна з існуючих систем не відповідає майбутнім потребам в повній мірі. Це розуміння послужило приводом для появи ряду ідей щодо впровадження нових технологій, а також, виробничої виконавчої системи. За підсумками аналізу було запропоновано 16 різних проектів, які, при послідовній реалізації, допоможуть компанії відповідати майбутнім технічним і комерційним вимогам.

Оцінюється зміст технічних робіт і вартість кожного проекту; для кожного проекту готується короткий односторінкове резюме, яке може обговорити керівництво. (Див. Рис. 3).

Мал. 3. односторінкового опис потенційного проекту міграції

Для того, щоб вибрати пріоритетні проекти, оцінюються потенційні результати кожного з них. Результати оцінюються з точки зору бізнес-цілей, а також, надійності АСУ ТП.

Як правило, вам доведеться оцінювати кілька сценаріїв впровадження для оцінки загальної потреби в ресурсах і фінансових коштах для кожного плану (рис. 7). Одним з основних обмежень, які треба враховувати, є «вікна» в виробничому процесі, під час яких можна замінювати або модифікувати системи. Як правило, ці «вікна» припадають на вихідні - і це серйозне «пляшкове горло».

Мал. 7. Консолідований огляд графіка міграції

Оскільки часу на заміну систем і їх наладку завжди «в обріз», підготовка повинна бути дуже ретельною. Все повинно бути розплановано в деталях. Важливим аспектом планування є перевірка впроваджених систем.

В описуваному нами випадку реалізація довгострокового плану міграції була виконана в шести різних потоках, см рис. 8.

Мал. 8. Організація проектів міграції в шести різних потоках

Частиною підготовки є ретельна оцінка і попередження ризиків проекту. На рис. 9 показані типові ризики, характерні для проектів міграції.

Мал. 9. Оцінка типових ризиків проектів міграції

Процеси для підтримки бізнесу

Підхід до управління життєвим циклом і планування довгострокової міграції, описаний в даній статті, визначається потребами бізнесу. Він включає оцінку поточних і майбутніх бізнес-цілей, а також, ретельний аналіз того, як технічні системи будуть підтримуватися або замінюватися для найкращої підтримки цих цілей. Підхід заснований на принципах TOGAF, які передбачають послідовну реалізацію проекту в залежності від наявності бюджетів і кваліфікованого персоналу. Оцінка поточної і майбутньої системних архітектур є ключовим елементом у визначенні майбутніх міграційних проектів. Нарешті, необхідно дотримання принципів управління змінами в організації, які забезпечують своєчасне залучення ключових учасників проекту, настільки важливе для успіху проектів міграції. Ефективність цього підходу була багаторазово продемонстровано на практиці.

Лейф Поулсен (Leif Poulsen) ( ), Провідний фахівець в області автоматизації та ІТ в NNE Pharmaplan. Володіє майстерні ступенем в галузі управління технологічними процесами. У NNE Pharmaplan Поулсен відповідає за розвиток технологій, методів і компетенцій в області промислової автоматизації та інформаційних технологій, і працює як старший бізнес-консультант.

Галузь PLM розвивається вже більше десяти років і настав той момент, коли підприємства, випробувавши рішення, обрані спочатку, цілком резонно вирішують змінити існуючу PLM на іншу, або істотно змінити конфігурацію поточної. І тут виникає питання міграції даних PLM зі старої системи в нову. Як ми знаємо, навіть трансляція самих геометричних даних є непростим і неоднозначно розв'язуваної завданням, міграція даних PLM - ще більш складний і поки маловідомий процес.

Як це буває

Вибір нової системи PLM був зроблений, команда керівників з полегшенням святкує результат складних зусиль цього вибору. На ділі, тільки тепер починається справжня робота, планування і здійснення міграції даних з існуючих систем в нову цільову платформу PLM. Існуючі дані компанії містять значну частину інтелектуальної власності (ІВ) і, отже, конкурентні переваги і капітал компанії. Успіх впровадження нової системи в значній мірі залежить від виконання ефективної міграції існуючих даних, інтелігентно, якісно і своєчасно.

Цей сценарій регулярно повторюється в тому чи іншому вигляді по всьому світу і в будь-якій галузі. З швидкими темпами вдосконалення технологій, посиленням конкурентного тиску, призводить до того, що багато компаній постійно оцінюють їх PLM-рішення і проводять поліпшення. Рішення може бути викликано визнанням того, що поточне рішення, або, частіше, його технічне обслуговування, або використання декількох систем, не влаштовують керівництво компанії. Крім того, є ще один загальний мотив - наслідки придбань компанії і усвідомлення того, що консолідація їх різних PLM рішень є виправданим. Ще один сценарій - необхідність масивної перенастроювання поточної платформи. Незалежно від причин змін, ефективне виконання змін буде залежати від успішної міграції існуючих даних на нову платформу.

Проблеми міграції даних

Міграція даних виносить на перший план численні запитання. Наприклад, може з'ясуватися, що це перша за багато років ревізія того, як компанія вибирала засоби керування даними про продукт. Для того щоб подолати очевидні недоліки в поточній моделі даних, яка розвивалася з плином часу, компанії, можливо, доведеться змінити частини моделі або розширити її. У будь-якому випадку, ці зміни нададуть додатковий тиск на процес переходу від старого до нового, просте перенесення даних може виявитися неможливим. Один з найважливіших моментів міграції полягає в тому, що спочатку потрібно визначити всі дані, які підлягають розгляду. Багато хто вважає, що мова йде лише про передачу цифрових даних, однак досвідчені фахівці напевно визнають, що якась частина критичної ІС компанії може все ще бути в друкованому вигляді, або взагалі її носіями є голови провідних співробітників.

Після того як дані, які підлягають міграції були ідентифіковані, необхідно розробити і виконати процеси перевірки їх правильності. Часто дані можуть виявитися застарілими, оскільки останні зміни не були внесені в більш ранні версії даних. Крім того, часто використовуються дубльовані дані (або підтримується в декількох системах), вимагаючи постійної або періодичної перевірки узгодженості та чистки даних. Визначення повного обсягу даних для міграції вимагає використання знань найбільш досвідчених співробітників компанії.

Можливо, однією з найбільших проблем міграції даних є терміни міграції. Старі дані будуть постійно поповнюватися і модифікуватися, так як компанія не може зупинити свою роботу і чекати завершення нової реалізації PLM. Крім того, в реальності колектив, який здійснює міграцію, має вельми обмежені технічні терміни для реального перемикання, типово це - вихідні або святкові дні. Необхідність укластися в доступне календарне час вимагає реалізації алгоритмів міграції за допомогою спеціальних інструментів, так як дані можуть легко містити в собі сотні тисяч (або навіть мільйонів) записів.

приклад рішення

Звернемося до досвіду тих, хто здійснював і здійснює міграцію даних PLM на регулярній основі. Одним з визнаних фахівців в області міграції даних PLM є німецька компанія PRION Group, що має одинадцятирічний досвід надання таких послуг і ефективний інструментарій для їх виконання. Так як портфоліо PRION включає в себе інтерфейси для найбільш поширених PDM і успадкованими системами, з якого дані повинні бути перенесені, в кожному конкретному випадку у компанії немає необхідності заново розробити ПО для міграції. Це дозволяє швидко розробити план переходу з урахуванням особливостей конкретної компанії і швидко виконати міграцію, щоб мінімізувати її вплив на розвиток продукту і виробництва. На малюнку нижче зображено схема типового процесу міграції даних за методологією PRION.

Найбільш істотно те, що працездатність цієї схема багаторазово підтверджена виконаними проектами міграції даних PLM у численних клієнтів PRION. Більш того, неодноразові спроби провести пряму трансляцію даних з однієї системи PLM в іншу довели 100% непрацездатність такого примітивного підходу. Серед факторів, що визначають такий стан справ: збір даних з декількох джерел, необхідність перетворення і чищення даних, їх атестації та завантаження в нову систему (и), які також можуть бути фізично розподілені. Таким чином, існують абсолютно неприйнятні при переході на нову платформу PLM.

Для зниження цих ризиків, PRION розробив засоби міграції, які використовують проміжну базу даних. Дані експортуються в проміжну базу даних і, перед завантаженням в нову цільову платформу PLM, перетворюються в цій базі даних. Такий підхід не призводить до негайного зміни в робочих даних і бізнес може тривати як зазвичай, в той час як розробляються правила і деталі процесу міграції даних. Критичним фактором для успіху міграції є створення системи управління змінами, щоб не тільки відслідковувати зміни, зроблені в ході міграції самих даних, але і зміни даних, зроблені після завантаження в нову платформу PLM. Ця система управління змінами повинна підтримувати конкретні вимоги замовника від самого процесу міграції до запуску нової системи в експлуатацію в реальних умовах.

Той факт, що PRION може використовувати багато з сценаріїв міграції зі своєї великої бібліотеки, яка була розроблена для колишніх клієнтів знижує ризики міграції та знижує витрати для майбутніх клієнтів значно. Цей підхід допомагає у багатьох важких сценаріїв міграції, особливо коли цільова система є розподіленим рішенням.

Для отримання більш детальної інформації про інструменти та послуги PRION рекомендую звернутися на сайт

Передача даних - це переміщення збереженої цифрової інформації між комп'ютерами, системами або форматами. Перенесення даних відбувається по ряду причин, включаючи заміну або обслуговування сервера, зміна центрів обробки даних, проекти консолідації даних і оновлення системи. Оскільки велика частина корпоративних знань і бізнес-аналітики компанії міститься в її даних, будь-який проект міграції даних повинен бути ретельно виконаний, щоб мінімізувати ризики.

Розвантаження «Міграція даних»

Перенесення даних являє собою значний ризик безперервності бізнесу, якщо він виконаний неправильно. Втрата даних, звичайно, є гіршим сценарієм, але компанії також повинні мати справу з часом простою, проблемами сумісності та спільною проблемою продуктивності системи. Перенесення даних ускладнюється через велику кількість даних, різних форматів даних та відмінностей в даних в корпораціях.

Щоб звести до мінімуму ризики міграції даних, компанії створюють докладні політики перенесення даних, які в міру необхідності припиняють резервне копіювання, порядок переміщення і паралельні середовища даних. Якщо компанія не може запускати середу попередньої міграції при підготовці нового середовища, тоді буде значний час простою, так як бізнес-операції над поточними додатками припиняються, щоб дозволити міграцію даних. Цей тип перенесення зупинки, перенесення і запуску може знадобитися при переході на нові платформи або при наявності жорстких обмежень на фізичне зберігання, а для існуючої технології зберігання потрібні свопи або виправлення.

Міграція даних з нульовим часом простою

Модель міграції з нульовим часом простою залежить від наявності достатньої кількості сховища для створення і запуску двох повних середовищ. Повна копія даних компанії береться в нове середовище і перевіряється, поки співробітники залишаються в старому середовищі. Помилки розробляються з нової системи, гарантуючи, що всі додатки все ще працюють, і все там, де має бути. По завершенні тестування з'являється нова копія, і всі співробітники переходять на нову середу. Старе середовище даних іноді залишається відкритою протягом декількох місяців, щоб співробітники могли отримувати файли зі старої системи даних, але не записували нові дані на ці сервери. У всіх міграціях даних виконується перевірка даних після міграції для перевірки втрати даних.

Одна річ, яка може поліпшити міграцію даних, полягає в очищенні і стандартизації практики даних до міграції. Організація даних компанії часто є відображенням різних звичок в подачі своїх людей. Двоє людей з однаковою роллю можуть використовувати абсолютно різні методи. Наприклад, збереження контрактів по постачальнику в одному випадку, а також протягом фінансового року і місяця в іншому. Уніфікація методів даних може бути набагато більш важливим завданням, ніж фактична міграція даних, але чисті, когерентно організовані дані, підкріплені чіткими політиками, допомагають майбутнім доказам даних компанії для багатьох міграцій ще попереду.