Концепции, методы и способы миграции основных и переменных данных в корпоративных информационных системах (часть 2)

Подробности

Опубликовано: 01.01.2020 10:28

Автор: Степанов Дмитрий Юрьевич

Просмотров: 4333

Аннотация: в статье определяется стратегия мигрирования данных, заданная такими ключевыми параметрами, как: структура команды миграции данных, число тестовых миграций и технических систем для их проведения, объемом переносимых данных в контексте тестовых миграций, а также необходимостью раннего переноса основных данных.
Скачать: PDF (статья), PDF (выпуск №10).
Ключевые слова: миграция данных в ERP-систему, маппинг файл, legacy система, миграция данных SAP, миграция данных с помощью SAP, руководство по миграции из SAP, SAP MDG перенос данных,миграция с SAP на 1C, SAP миграция данных, миграция SAP.

3.5. План перехода и миграции

Ссылка на 1-ю часть статьи. Миграция данных непрерывно связана с переходом к использованию системы в продуктивном режиме. Под планом перехода понимается череда операций для перевода работы компании к использованию новой разработанной информационной системы. Он представляет собой перечень задач, которые  необходимо выполнить  для того, чтобы начать полноценно применять новую систему. План перехода  можно разбить на три составляющие:

• технический план перехода;
• бизнес-план перехода;
• миграция данных.

В свою очередь, в бизнес-плане перехода отражаются такие моменты как:

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

План перехода и план мигрирования сильно коррелируют между собой, так как план миграции является составной частью перехода при внедрении информационной системы. Рассмотрим две опции по мигрированию данных при переходе к новой системе (рис. 3.6):

• 1-я опция, предполагает, что миграция основных и переменных данных ведется последовательно, для чего:
  • завершаются все активности по обработке основных данных в исторической системе;
  • запрещаются изменения основных данных в исторической системе; 
  • основные данные мигрируются из исторической в целевую систему;
  • выполняются аналогичные операции по завершению и приостановке изменений переменных данных в исторической системе;
  • останавливается работа компании для переноса переменных данных в целевую систему, так как необходимо полностью  блокировать ввод любой информации в исторической системе;
  • в момент остановки работы компании выполняется перенос переменных данных в целевую систему, проводятся контроль, валидация и проверка;
  • затем возобновляется работа компании, выполняются первые активности в новой системе.
• 2-я опция, когда основные данные мигрируются из исторической системы в целевую значительно раньше переменных данных, для этого:
  • большая часть объема основных данных мигрируется из исторической системы в целевую значительно раньше периода остановки работы компании;
  • основные данные до запуска целевой системы могут изменяться в исторической системе;
  • эти изменения и оставшаяся часть невнесенных ранее основных данных в последующем вносятся в целевую систему путем  ручных операций в виде дельта-миграции;
  • шаги по миграции переменных данных этой опции аналогичны порядку их миграции, рассмотренному в 1-й опции.

Реализация 2-й опции по мигрированию основных данных требует предварительной подготовки целевой системы, для чего необходимо:

• выполнить перенос в целевую систему разработок и настроек, касающихся организационной структуры компании;
• мигрировать справочники данных в новую систему;
• перенести средства автоматизированной загрузки в целевую систему. 

Рис. 3.6. Опции переноса основных данных 

Суммируем особенности переноса основных и переменных данных. Особенности переноса основных данных заключаются в следующем:

• миграция основных данных по времени возможна значительно раньше миграции переменных данных;
• миграция основных данных не требует остановки работы компании;
• основные данные очень редко подлежат изменению.

К особенностям миграции транзакционных данных относят:

• невозможность переноса переменных данных заранее, так как они постоянно изменяются;
• миграция переменных данных требует остановки работы компании. Период остановки работы компании преимущественно включает в себя активности по мигрированию именно переменных данных.

Проанализируем пример миграции объектов для критического процесса отгрузок клиентам. Период остановки работы компании обычно обусловлен миграцией транзакционных данных. Для определения времени, необходимого для остановки работы компании, составляется расчет, исходя из состава и объема переменных данных, подлежащих обязательной миграции в новую систему. Пример подобного расчета:

• миграция основной записи партии – 1 день;
• перенос классификации партии – 1 день;
• миграция складских запасов – 3 дня;
• перенос дебиторской задолженности – 2 дня;
• миграция кредитных лимитов – 1 день.

Таким образом, для того чтобы выполнить миграцию переменных данных в полном объеме, необходимо приостановить работу компании на 8 дней. Для того чтобы сократить период отключения необходимо запараллелить те процессы миграции, которые возможно. В рассмотренном примере можно запустить следующие процессы параллельно, так как они не зависят друг от друга:

• миграция дебиторской задолженности и классификации партий – 1 день; 
• миграция кредитных лимитов и складских запасов – 3 дня;
• миграция основной записи партии – 1 день.

Тогда, с учетом запараллеливания отдельных процессов миграции, срок остановки работы компании сократится до 5 дней.

3.6. Организация процесса миграции

Для формирования команды миграции данных при внедрении ERP-системы возможны два подхода:

• в проектах внедрения «с нуля» чаще всего используется функциональный подход к организации команды. Суть подхода заключается в том, что каждая из функций организации (логистика, финансы, кадры, данные и др.) представляется отдельной группой внедрения, которая включает руководителя и непосредственных исполнителей. В этом случае выделяется независимая команда миграции, осуществляющая перенос основных и переменных данных для всех прочих групп;
• в проектах тиражирования преимущественно применяется матричный подход. Суть матричного подхода заключается в том, что отдельно выделяются функциональные группы по логистике, финансам, кадрам и др., но независимой группы по миграции нет. Однако для переноса данных назначается лидер по мигрированию, хотя непосредственных исполнителей у него нет. Вместо этого сотрудники для миграции данных заимствуются на определенный процент занятости из смежных функциональных групп.

В зависимости от вида миграции ответственность за выполнение процедур очистки, выгрузки, конверсии и загрузки будут нести разные стороны. В частности, с увеличением номера тестовой миграции данных, заказчик вовлекается в процедуру мигрирования все больше и больше. Например:

• при проведении 1-й тестовой миграции заказчик  решает  задачи по очистке, выгрузки данных, в то время как конверсию и загрузку делает поставщик;
• во 2-й тестовой миграции заказчик больше вовлечен в ход переноса: он выполняет операции по очистке, выгрузки и конверсии информации из исторической системы;
• 3-й тестовая миграция подразумевает, что практически все шаги мигрирования, включая проверки ведутся исключительно заказчиком.

В рамках продуктивной миграции загрузка данных в целевую систему ведется поставщиком, хотя проверка загруженных результатов осуществляется заказчиком. Обычно, все, что касается исторической системы и операций, которые отражаются в ней (очистка, выгрузка, трансформация) преимущественно относятся к сфере ответственности заказчика. В то время как загрузка информации в целевую систему является непосредственной ответственностью поставщика. При разработке и конфигурировании автоматизированных средств миграции, например LSMW в SAP ERP, необходимо предусмотреть механизмы:

• создания записи;
• обновления записи;
• удаления записи, ведь, если данные будут загружены неверно, потребуется процедура их изменения или удаления.

Чаще всего миграция информации из исторической системы в целевую выглядит следующим образом:

• очистка данных в исторической системе ведется до начала продуктивной миграции;
• необходимые данные выгружаются из исторической системы;
• в ходе трансформации выгруженных данных готовится шаблон загрузки в нужном формате;
• трансформированные данные загружаются в целевую систему. Все новые данные, которые были получены по результатам загрузки, будут храниться в мэппинговых файлах. Допустим, если номер основной записи клиента в исторической системе имел одно значение, а при загрузке в целевую систему это значение поменялось, то готовится файл сопоставления, связывающий старый и новый номер клиента.

Как было рассмотрено ранее, тестовая миграция данных выполняется неоднократно, причем каждый новый тестовый перенос увеличивает процент мигрируемых данных. Получается, что одни и те же тестовые данные необходимо мигрировать многократно. Если несколько миграций проводить в одну и ту же систему, это приведет к ошибкам. Поэтому часто готовят различные технические среды независимо для каждой тестовой миграции 1-3. Тем самым может быть протестирован полный объем данных на каждой тестовой волне мигрирования.

4. Имплементация стратегии миграции

Проанализировав составные части процесса миграции, сформулируем стратегию переноса данных. По определению стратегия – это общий, не детализированный план действий, охватывающий длительный период времени. В контексте мигрирования данных стратегия переноса информации будет разъяснять следующие вопросы:

• организационная структура команды по миграции данных;
• список объектов миграции;
• владельцы данных;
• способы миграции данных;
• распределение ответственности внутри проектной команды;
• число тестовых миграций;
• процент данных для загрузки в тестовых миграциях;
• распределение ответственности заказчика;
• число технических систем для миграции;
• параметры контроля тестовых миграций;
• ранняя миграция основных данных.

Каждый из этих показателей мы детально рассмотрели в предыдущем разделе. Выделим особенности самых критичных параметров стратегии мигрирования данных:

• матричный и функциональный подходы к формирования команды по миграции фактически являются равнозначными, вопрос лишь в том, какая из групп возьмет на себя трудозатраты по переносу данных. Существенным плюсом выделения отдельной команды по мигрированию видится то, что это позволяет эффективнее выполнять планирование, так как исполнители занимаются только вопросами переноса данных, не отвлекаясь на прочие функциональные задачи;
• число тестовых миграций обычно сопоставляют с количеством проводимых испытаний, то есть с 3-я: системное, интеграционное и приемочное тестирования. На практике количество тестовых миграций бывает больше, но не меньше 3-х. Чем больше число тестовых переносов планируется, тем больше трудозатрат потребуется на их реализацию, в то же самое время большее число ошибок будет выявлено и исправлено до продуктивной миграции;
• количество технических систем для миграции обычно задают меньшим или равным количеству тестовых переносов информации. Минимизация числа тестовых систем может исключить выгоды от проведения тестовых миграций, так как перенос информации в этом случае происходит в далеких от продуктивной реальности условиях;
• процент данных для загрузки в тестовых миграциях 1-3 обычно стараются довести до границы 100%, что способствует скорейшему обнаружению и устранению ошибок. Однако, чем быстрее процент приближается к пороговому значению, тем больше потребуется трудозатрат проектной и бизнес команд. Поэтому компромиссным считается подход, согласно которому процент загрузки увеличивается планомерно с заданным шагом, от одной тестовой миграции к последней. Последний тестовый перенос знаменуется миграцией объема данных, близкому к продуктивному, то есть к 100%;
• ранняя миграция основных данных ведется в ситуации, когда необходимо сократить период остановки работы компании. В противном случае потребность в ней будет отсутствовать.

5. Оценивание применения стратегий

Рассмотрим несколько примеров имплементации стратегии мигрирования данных, заданной указанными 5-ю ключевыми параметрами, в проектах внедрения системы SAP ERP. Решения на базе SAP имплементировались на российских и зарубежных предприятиях за последние несколько лет:

• российская металлургическая компания (проект внедрения «с нуля»);
• российская нефтяная компания (два проекта внедрения «с нуля», один проект тиражирования);
• западная фармацевтическая компания (два проекта тиражирования);
• западная продуктовая компания (проект тиражирования);
• западная алкогольная компания (два проекта тиражирования).

Сгруппируем в единой таблице значения параметров, определяющих стратегии миграции для проектов имплементации системы SAP ERP. Табл. 1 позволяет сформулировать следующие выводы. В большинстве проектов внедрения ERP-систем применяется функциональная структура команды по миграции данных вне зависимости от вида проекта. Тестовая миграция данных осуществляется в большинстве проектов имплементации корпоративных систем, в среднем выполняется около 2-х тестовых переносов данных. Число технических систем, подготавливаемых для испытаний переноса данных, приблизительно равно количеству тестовых миграций. Ранний перенос основных данных осуществляется практически всегда для трех критичных SAP-объектов: материалы, дебиторы и кредиторы.

Табл. 1. Параметры стратегий миграции для проектов внедрения SAP ERP

6. Заключение

В работе были рассмотрены отличия основных и переменных данных, способы их миграции, продемонстрирована взаимосвязь плана миграции и перехода, определены параметры, задающие стратегию переноса данных на примере системы SAP ERP. Стратегия мигрирования задана такими ключевыми параметрами, как: структура команды миграции данных, число тестовых миграций и технических систем для их проведения, объемом переносимых данных в контексте тестовых миграций, а также необходимостью раннего переноса основных данных. Подчеркивается, что чаще всего команда миграции формируется по функциональному принципу, тестовые миграции являются обязательным атрибутом проектов внедрения ERP-систем, а необходимость раннего переноса основных данных даже не обсуждается в виду ее критичности. 

Литература

1. Еременко Я.O. Особенности миграции данных в SAP ERP // Корпоративные информационные системы. – 2019. – №3(7). – С. 22-28. – URL: https://corpinfosys.ru/archive/issue-7/67-2019-7-migration.
2. Kalwachwala H., Chahal S., Cheekoti S. SAP Master Data Governance.: SAP Press, 2019. – 772 p.
3. Densborn F., Finkbohner F., Gradhl J. Data migration with SAP.: SAP Press, 2016. – 550 p.
4. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень данных / МГТУ МИРЭА. - М., 2017.
5. Степанов Д.Ю. Проблемы внедрения корпоративных информационных систем: уровень приложений // Менеджмент сегодня. – 2015. – т.87, №3. – c.180-191.
6. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.

Выходные данные статьи

Степанов Д.Ю. Концепции, методы и способы миграции основных и переменных данных в корпоративных информационных системах (часть 2) // Корпоративные информационные системы. – 2020. – №2(10). – С. 38-46. – URL: https://corpinfosys.ru/archive/issue-10/115-2020-10-datamigration.

Об авторе

Степанов Дмитрий Юрьевич – кандидат технических наук, доцент МИРЭА, принимал участие более чем в 10 проектах внедрения корпоративных информационных систем на базе SAP, Microsoft и Sage. Специализируется на управлении материальными потоками, сбытом и системой документов. Автор более 25 статей, в том числе публикации в журналах «Логистика сегодня», «Вопросы экономических наук», «САПер» и др. Электронный адрес автора: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Статьи выпуска №10

1. Об учете субсидий малому и среднему бизнесу на возмещение потерь от коронавируса;
2. Порядок, условия и сроки хранения бухгалтерских документов;
3. Agile Scrum для реализации автоматизированного рабочего места врача (часть 1);
4. Концепции, методы и способы миграции данных (часть 2);
5. Сторителлинг как новая технология подачи информации.