Миграция данных. 
Управление жизненным циклом информационных систем

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

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

Другой категорией данных для переноса является информация из функционирующих на предприятии программных решений и legacy-систем, на смену которым внедряется новый программный продукт. При корректной подготовке на стадии проектирования передача данных в новую систему организовывается автоматизированно, через специальные коннекторы и шины данных. В противном случае миграция данных становится «ночным кошмаром», когда они должны быть в ручном режиме выгружены из существующих систем, приведены к единому формату и после определения соответствия полей и типов данных загружены в новую систему. Но ведь данные в существующих системах могут обновляться ежесекундно. Насколько допустйм этот простой на время миграции и как избежать всех проблем, ассоциированных с распределенным онлайн-вводом, не говоря уже о проблеме ресурсоемкое™ и неимоверной трудоемкости данного процесса, связанного с огромным риском потери информации?

В таких случаях миграция организуется в онлайн-режиме. Такой способ предполагает перенос данных при непрерывной работе всех серверов и приложений. Это особенно важно для критических для бизнеса приложений с высокими требованиями к доступности: Oracle, Exchange, биллинговых систем, систем электронной коммерции. Новые данные внедряются в уже существующий поток информации, объединяются с имеющимися в системе данными на логическом уровне через отдельный адрес диска, который после успешной миграции удаляется или архивируется.

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

• • недостаточные компетенции/опыт команды проекта в миграции данных (в том числе в части формирования документации об уже осуществленных проектах);
• • отсутствие единого ответственного за данные, что может привести к невозможности определить наиболее корректные и актуальные данные;
• • низкое качество переносимых данных (дублирование, некорректные форматы данных);
• • нестабильность целевой системы для переноса данных — если разработка еще не завершена и миграция данных выполнена преждевременно, могут возникнуть ошибки или потеря информации;
• • несвоевременность организации синхронизации данных — актуализация данных должна производиться в новой системе сразу после миграции;
• • низкая степень документированное™ процесса миграции — данный риск относится не только к невозможности использования полученного опыта для выполнения дальнейших проектов, но и в большей степени связан с невозможностью в случае необходимости продемонстрировать аудиторам или компетентным контролирующим органам отчеты по датам и масштабам перемещения данных. Л значит, потенциально может возникнуть огромное количество проблем, связанных с доказательством достоверности предоставленной отчетности. Особенно это актуально, если данные для отчетности выгружались в период параллельной работы старой и новой систем, при наличии различий в объемах данных, хранившихся в них в конкретный момент.

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

• различия в написании объектов;

Пример

• • Организационно-правовые формы и формы собственности («АО» Вымпел, ЗАО «Вымпел», ВЫМПЕЛ). Это приводит к путанице: не ясно, идет речь о разных предприятиях или об одной и той же компании?
• • Использование латиницы и сокращений: Ivanov Ivan, Иванов И.
• • несовпадение информации из-за устаревания данных;

Пример

В одной системе в качестве адреса ООО «Вымпел» указывается г. Воронеж, а в другой — г. Москва. Разница может быть обусловлена переездом компании либо же разной трактовкой понятия «адрес» сотрудниками, вводившими информацию в систему: в первом случае — юридический адрес компании, во втором — фактический.

• несовпадение форматов данных.

Пример

• • Неиспользование выпадающих списков для полей с ограниченным числом значений: г. Балашиха в одной системе и «Московская область» в другой.
• • Использование текстовых полей для написания цифр (например, в случае миграции Excel-таблиц): 84 951 234 567 добав 1111.
• • Стиль написания цифр: +7 (495) 123-45-67, 84 951 234 567.

Во всех этих случаях необходима тщательная выверка всех данных, проводящаяся частично в автоматизированном режиме (например, для замены «+7» в телефонных номерах на «8», удаления лишних пробелов и других символов), частично в ручном режиме пользователями.