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

05.11.2019

Лейф Поулсен для 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 Poulse n) ( ), ведущий специалист в области автоматизации и ИТ в 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 рекомендую обратиться на сайт

Разработка общих требований к миграции данных

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

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

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

Параллельно с выбором стратегии проведения миграции данных менеджментом проекта и/ или бизнес-аналитиком должна быть произведена выявление типовых рисков миграции данных. Для каждого выявленного риска должна быть выбрана стратегия (методы) работы с риском и разработан комплекс мероприятий по предотвращению риска. Стратегией предотвращения риска может быть одна из следующих :

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

В таблице 1, приведена матрица типовых рисков миграции данных и способы работы с каждым из таких рисков. В ячейках матрицы приведены примеры мероприятий по работе с каждым из рисков в рамках каждого метода предотвращения риска.

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

Таблица 1 Матрица рисков и возможных стратегий работы с рисками этапа миграции

Стратегия работы с риском	Снижение	Передача	Принятие
Риски составления технической спецификации	Проработка требований к миграции совместно с бизнесом, владельцами и потребителями мигрируемых данных	Привлечение к работам по составлению технической спецификации консультантов	Формирование резерва бюджета и времени на проекте для работы с потенциальными запросами на изменение
Риски тестирования	Проработка тестовых планов и сценарием с привлечением бизнес-пользователей	Передача пакета работ по тестированию отдельной команде с заранее определенными условиями приемки их резудьтатов	Формирование резерва времени и бюджета на потенциальные дополнительные работы вследствие неполного тестирования миграционного ПО и размещенных данных
Риски процесса получения и загрузки данных	Проработка требований к тестовой выгрузке. Проведение «тестовой» миграции с использованием тестовой выгрузки		Формирование резерва бюджета и времени для повторных получений выгрузок и итеративной загрузки
Стратегия работы с риском	Снижение	Передача	Принятие
Риски, связанные с работой проектной команды
Риски размещения данных в целевой системе	Параллельная проработка модели данных “as is” и “ to be” для нивелирования различий в форматах и способах работы с данными в источнике и приемнике		Формирование резерва времени и бюджета для доработок функциональности системы-приемника

Организация планирования работ по миграции данных

Входной информацией для составления планов работ по миграции является стратегия миграции данных, сформулированная в рамках разработки общих требований к миграции данных.

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

План работ по миграции определяет набор задач и ответственных за их выполнение, распределенных с помощью матрицы RACI. Проектный план работ по миграции должен содержать пакеты задач и работ для каждого из этапов миграции: от подготовительного до пост-миграционного этапа работ. С учетом результатов анализа проектного опыта была разработана ИСР, позволяющая избежать рисков и соответствующая «эталонным» теоретическим подходам к организации миграции данных.

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

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

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

1. Предмет (тема) коммуникации.
2. Необходимость взаимодействия ролевых групп внутри команды;

Кто должен участвовать в коммуникации? Какие ролевые группы?

3. Какой тип взаимодействия приемлем?
4. Что должно являться выходом коммуникации?
5. Необходимость взаимодействия с проектной команды и бизнес-пользователей;
6. Кто должен участвовать в коммуникации со стороны проектной команды и со стороны бизнеса?
7. Какой тип взаимодействия с бизнес-пользователями приемлем?
8. Что должно являться выходом коммуникации с бизнес-пользователями?
9. Кто должен быть осведомлен о результатах коммуникации?

Шаблон плана коммуникаций на этапе миграции данных приведен в таблице 2 ниже (Таблица 2).

Таблица 2 Шаблон плана коммуникации на этапе миграции данных

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

Разработка и документирование бизнес-требований к миграции данных

Разработка и документирование требований к миграции данных должно осуществляться в несколько этапов. В рамках разрабатываемой методики в этап разработки бизнес-требований к миграции данных будет также включен шаг проведения и документирования результатов обследования организации-заказчика. Цель этапа разработки бизнес-требований к миграции данных - разработка полного пакета требований к специализированному ПО для миграции данных, а также к составу данных, мигрируемых в целевую систему.

1. Обследование эксплуатируемой информационной системы

Обследование эксплуатируемой информационной системы хронологически должно быть первым этапом работ в рамках разработки требований к миграции данных.

Обследование существующей информационной системы в рамках разработки требований к миграции данных может проводиться в рамках работ по обследованию бизнеса всего проекта внедрения ИС. Обследование в рамках разработки требований к миграции данных должно быть направлено на создание модели данных `as is". Модель данных `as is" позволит подготовить требования к составу мигрируемых данных из системы-источника в систему-приемник.

Модель данных `as is" описывает все объекты данных, которые используются в эксплуатируемой системе. После составления такой модели заказчику будет проще выбрать перечень объектов данных для переноса в систему-приемник. В такой модели должны быть указаны имена сущностей, а также описан их атрибутный состав и взаимосвязи между сущностями с указанием их кардинальности.

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

Помимо составления модели данных `as is" на этапе обследования должны быть описаны правила работы со словарями и справочниками в эксплуатируемой системе. В частности, должны быть описаны следующие моменты для каждого словаря:

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

Формат спецификации требований к миграции словарей из системы-источника в целевую систему приведен в таблице и пример заполнения такой спецификации приведен.

2. Разработка требований к профилю данных для миграции

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

Бизнес-пользователи являются источниками для получения ответов на следующие вопросы о профиле данных для миграции данных:

1) Будут ли мигрированные данные являться входными для работы бизнес-процесса, автоматизированного в проектируемой системе? Ответом на данный вопрос должна стать таблица-описание соответствия объектов данных системы-источника и бизнес-процессов, автоматизированных в целевой системе.
2) Какой временной промежуток должен быть определен для миграции данных? При этом должны быть учтены положения нормативных и организационно-распорядительных документов. Ответом на данный вопрос должна стать таблица соответствия объекта данных и временного горизонта выгрузки данных из системы-источника.
3) Какому объекту данных целевой системы соответствует каждый из выбранных для миграции объектов данных системы-источника? Ответом на данный вопрос должна стать таблица маппинга объектов данных системы-источника и системы-приемника.
4) Есть ли в атрибутном составе объектов данных системы-источника поля или группа атрибутов, которые не будут использоваться в целевой системе? Ответом на данный вопрос должна стать таблица описания атрибутного состава объектов данных с проставленным флагом: используется/ не используется в целевой системе.
5) Есть ли в атрибутном составе объектов данных системы-источника поля или группы атрибутов, которые не соответствуют по типу данных полям в целевой системе? Ответом на данный вопрос должна стать таблица описания атрибутного состава объектов данных с проставленным флагом и расшифровкой несоответствий.
6) Происходила ли модернизация системы-источника, результатом которой стало значительное изменение в структуре данных, которые необходимо мигрировать? Примеры изменений:
- - Изменение состава обязательных атрибутов;
- - Изменение правил хранения объектов данных;
- - Значительное изменение структуры объекта данных, приводящее к изменению объемов данных.

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

7) Какое функциональное подразделение или конкретные пользователи являются владельцами данных? Ответом на этот вопрос должна стать таблица соответствия объектов данных и сотрудников заказчика.

Сотрудники ИТ-подразделения являются источниками для получения ответов на следующие вопросы о профиле данных для миграции:

1) Где физически хранятся данные, выбранные бизнес-пользователями для миграции в целевую систему? Что является источником данных: корпоративное приложение, система или источники за пределами организации-заказчика? Ответом на данный вопрос должна стать таблица соответствия объектов данных и их хранилищ (имя и тип БД, имя таблицы/таблиц в БД).
2) Позволяет ли метаинформация мигрируемого контента разработать алгоритмы миграции? Возможно ли произвести анализ структуры данных на основе метаинформации?
3) Есть ли технологические ограничения системы-источника, которые отражаются на структуре данных, формах хранения и работы с данными? Ответом на данный вопрос должно стать полное описание технологических ограничений системы-источника в разрезе объектов данных для миграции.

Сотрудники ИТ-подразделения и бизнес-пользователи совместно должны произвести оценку критичности потенциальных ошибок при переносе данных из системы-источника в целевую систему. В частности, бизнес-пользователи и сотрудники ИТ-подразделений должны проанализировать взаимосвязи объектов данных на уровне используемой БД для определения перечня возможных проверок целостности данных при переносе в целевую систему.

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

3. Разработка требований к утилите миграции
1) Требования к очистке и логическим проверкам данных

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

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

- Заполнены ли все обязательные атрибуты?
- Физический тип данных каждого атрибута в системе-источнике и системе-приемнике совпадают?
- Длины значений атрибутов в объекте данных удовлетворяют требованиям в целевой системе?
- Формат хранения данных (даты, десятичные числа) соответствуют требованиям в целевой системе?
- Идентификаторы объектов данных в системе-источнике позволяют их однозначно различить?

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

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

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

- Недостающие обязательные атрибуты могут быть заполнены заранее определенными значениями - «заглушками».
- Значения атрибутов, длина которых не соответствует требованиям целевой системы, должны быть сокращены.
- Формат дат системы-источника должен быть приведен к формату хранения дат системы-приемника.
- Формат хранения десятичных числовых данных должен быть приведен к формату хранения десятичных числовых данных в целевой системе.
- Атрибуты, физически тип данных которых не соответствует требованиям целевой системы, должны быть преобразованы. Например, текстовые значения могут быть приведены к целочисленным.

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

2) Требования к именованию сущностей в системе-приемнике

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

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

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

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

3) Требования к логированию миграции данных

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

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

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

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

· Вид мигрируемого объекта данных;
· Система-источник;
· Уникальный идентификатор объекта данных в системе-источнике;
· Уникальный идентификатор объекта данных в системе-приемнике;
· Дата и время проведения загрузки для данного объекта данных;
· Сформированное утилитой миграции имя/номер для данного объекта данных, в случае если для данного объекта данных был применен алгоритм формирования имен/ номеров сущностей;
· Флаг: был ли объект данных мигрирован в систему-приемник или был исключен из загруженных данных;
· Причина, по которой объект был исключен из загруженных данных - состав логических проверок и правил;
· Описание ошибки, возникшей в ходе миграции объекта данных, если такая произошла.

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

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

Фрагмент лога утилиты миграции приведен в приложении 4 (Приложение 4 - Фрагмент лога утилиты миграции).

Проведение тестирования в рамках работ по миграции данных

Работы по тестированию состоит из следующих пакетов работ:

1. Первичное тестирование миграционного ПО на соответствие технической спецификации;
2. Бизнес-тестирование миграционного ПО на соответствие требованиям бизнеса к алгоритмам трансформации данных во время миграции;
4. Тестирование работы функциональности системы-приемника после размещения мигрируемых данных;

Ниже приведена последовательность шагов, которые должны быть предприняты проектной командой для проведения каждого из этапов тестирования.

Первичное тестирование миграционного ПО должно выявить и устранить технические сбои и дефекты разработанной утилиты миграции. Такое тестирование должно проводиться силами команды тестировщиков в соответствии с разработанными тест-кейсами. При этом после доработок ПО в случае выявленных ошибок обязательным является проведение регрессионного тестирования утилиты.

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

1. Определить по логу утилиты миграции игнорированные при загрузке объекты данных.
2. Убедиться, что эти объекты в системе-источнике удовлетворяли условиям применения логических проверок или механизмов трансформации.
3. В случае выявления несоответствия зафиксировать ошибку работы утилиты миграции.

Ошибки, зафиксированные в ходе тестирования, должны фиксироваться в таком виде, чтобы можно было однозначно определить источник их появления - алгоритм или правило, сработавшее неверно.

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

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

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

Работа с тестовой выгрузкой - завершающий этап тестирования миграционного ПО. После обработки утилитой миграции тестовой выгрузки становится возможной оценка необходимого планового времени для загрузки всего массива мигрируемых данных. Успешное размещение тестовой выгрузки в системе-приемнике должно означать внутреннюю приемку утилиты миграции и возможность перехода к работам по загрузке промышленной - полной выгрузки из системы-источника в целевую систему.

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

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

1. Тестирование работоспособности системы-приемника;
2. Детальное тестирование функциональности системы-приемника.

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

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

Детальное тестирование функциональности системы-приемника предполагает запуск всех автоматизируемых бизнес-процессов, для которых входными данными являются мигрированные данные. В случае если в состав загруженных данных входит более одного типа объектов данных, то тестовые сценарии должны быть предусмотрены для каждого мигрированного типа данных. Результаты тестирования функциональности системы-приемника должны фиксироваться в журнале тестирования.

В соответствии со стандартом ANSI журнал (лог) тестирования миграции данных должен иметь следующую структуру:

1. Идентификатор тест-кейса;
2. Описание операции в рамках тест-кейса;
3. Описание ошибки во время выполнения операции в рамках тест-кейса;
4. Влияние ошибки на функциональность системы;
5. Влияние ошибки на связанные операции тестирования.

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

a) Входящие данные для операции;

b) Ожидаемые результаты;

c) Полученные результаты;

d) Дата и время выполнения операции;

e) Количество попыток выполнения операции;

f) Ответственные за тестирование члены проектной команды;

g) Окружение операции в рамках тест-кейса.

Фрагмент журнала тестирования функциональности системы-приемника приведен в приложении 5 (Приложение 5 - Журнал тестирования результатов миграции).

В данной статье мы хотели бы систематизировать наш опыт проведения миграции данных в крупных корпоративных проектах, связанных с переходом Заказчиков на работу в конфигурациях «1С:Предприятие 8».

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

Термины и определения

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

Следует отличать миграцию данных от интеграции данных. Интеграция, в отличие от миграции - это постоянная часть архитектуры IT, и ответственна за потоки данных между различными системами и хранилищами данных - и является процессом, а не деятельностью по осуществлению проекта.

Схема миграции в общем случае выглядит следующим образом:

Рис. 1

Исторические системы - базы данных компании Заказчика, которые планируется полностью или частично заменить при внедрении новой системы.

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

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

Как современную альтернативу в качестве транспорта возможно рассматривать формат xml -файлов.

Также существуют варианты использования промежуточной базы данных.

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

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

Шаблоны данных для загрузки - описание таблиц данных для загрузки в целевую систему.

Этапы миграции

Рассмотрим поэтапно процесс подготовки и проведения миграции.

К организационным этапам миграции можно отнести следующие пункты:

· Определение стратегии миграции. На данном этапе Исполнитель и Заказчик договариваются о технологии проведения миграционных работ;

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

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

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

· Состав данных, подлежащих миграции. Справочные данные, классификаторы, транзакционные данные, остатки, обороты и пр.;

· Вопросы проверки качества, корректности и целостности данных в процессе миграции и по итогам;

· Вопросы отката к предыдущему состоянию в случае сбоев.

Остановимся подробнее на технологических этапах миграции.

Рис. 2

1.Подготовка шаблонов загрузки данных

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

Каждый шаблон в общем случае предназначен для одной или нескольких связанных таблиц в целевой системе-приёмнике.

В шаблоне указывается:

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

o Имя поля

o Признак обязательности заполнения поля

o Пример заполнения поля

o Примечание

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

· Описание заполнения непосредственно полей таблиц целевой системы в случае, если предусматривается что-либо отличное от переноса данных «один в один» из файла данных для загрузки. Актуально для ссылочных полей, например.

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

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 - для элементов

Если длина кода=11 символов и последние 4 символа <> "0000", то это элемент - "0", иначе группа - "1".

Полное наименование

Наименование элемента справочника

Наименование

Если ЭтоГруппа =1 , То "", ИначеЕсли ЭтоГруппа=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С:Предприятия», переход на новую систему может быть весьма трудоёмким.

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

Последнее обновление: 31.10.2015

Нередко возникает ситуация, когда модель меняется. Например, мы решили внести в нее новые свойства. Но при этом у нас уже имеется существующая база данных, в которой есть какие-то данные. И чтобы без потерь обновить базу данных ASP.NET MVC предлагает нам такой механизм как миграции. Например, у нас есть простая модель User:

Public class User { public int Id { get; set; } public string Name { get; set; } }

Соответсвенно есть контекст данных, через который мы работаем с бд:

Users { get; set; } }

И допустим, у нас есть вся инфраструктура для работы с этой моделью - представления, контроллеры, и у нас есть уже в базе данных несколько объектов данной модели. Но в какой-то момент мы решили изменить модельную базу приложения. Например, мы добавили еще одно поле в модель User:

Public class User { public int Id { get; set; } public string Name { get; set; } public int Age { get; set; } }

Кроме того, мы решили добавить еще одну модель, например:

Public class Company { public int Id { get; set; } public string Name { get; set; } }

Таким образом, контекст данных у нас уже меняется следующим образом:

Public class UserContext: DbContext { public UserContext() : base("DefaultConnection") { } public DbSet Users { get; set; } public DbSet Companies { get; set; } }

Мы можем добавить в представления для модели User дополнительное поле для свойства Age, можем создать контроллер и представления для новой модели, но при попытке добавить новый объект в бд, мы будем получать ошибку:

Контекст данных изменился, и теперь нам надо провести миграцию от старой схемы базы данных к новой. И первым делом найдем внизу Visual Studio окно Package Manager Console, введем в нем команду: enable-migrations и нажмем Enter:

После выполнения этой команды Visual Studio в проекте будет создана папка Migrations, в которой можно найти файл Configuration.cs . Этот файл содержит объявление одноименного класса Configuration, который устанавливает настройки конфигурации:

Namespace MigrationApp.Migrations { using System; using System.Data.Entity; using System.Data.Entity.Migrations; using System.Linq; internal sealed class Configuration: DbMigrationsConfiguration { public Configuration() { AutomaticMigrationsEnabled = false; ContextKey = "MigrationApp.Models.UserContext"; } protected override void Seed(MigrationApp.Models.UserContext context) { } } }

В методе Seed можно проинициализировать базу данных начальными данными. Теперь нам надо создать саму миграцию. Там же в консоли Package Manager Console введем команду:

PM> Add-Migration "MigrateDB"

После этого Visual Studio автоматически сгенерирует класс миграции:

Namespace MigrationApp.Migrations { using System; using System.Data.Entity.Migrations; public partial class MigrateDB: DbMigration { public override void Up() { CreateTable("dbo.Companies", c => new { Id = c.Int(nullable: false, identity: true), Name = c.String(), }) .PrimaryKey(t => t.Id); AddColumn("dbo.Users", "Age", c => c.Int(nullable: false)); } public override void Down() { DropColumn("dbo.Users", "Age"); DropTable("dbo.Companies"); } } }

В методе Up с помощью вызова метода CreateTable создается таблица "dbo.Companies" и производится ее настройка: создание столбцов, установка ключей. И также добавляется новый столбец Age в уже имеющуюся таблицу. Метод Down удаляет столбец и таблицу на случай, если они существуют. Фактически эти методы равнозначные выражению ALTER в языке SQL, которое меняет структуру базы данных и ее таблиц.

И в завершении чтобы выполнить миграцию, применим этот класс, набрав в той же консоли команду:

PM> Update-Database

После этого, если мы посмотрим на состав базы данных, то увидим, что к ней были применены изменения в соответствии с выполненной миграцией:

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