В данной статье мы хотели бы систематизировать наш опыт проведения миграции данных в крупных корпоративных проектах, связанных с переходом Заказчиков на работу в конфигурациях «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 . В результате данной работы составляется и поддерживается реестр мэппинга таблиц. Данный подэтап необходим для следующего подэтапа мэппинга полей и для отслеживания общего состояния дел по мэппингу.

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

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

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

В отличие от предыдущих этапов, данный этап - технический и предполагает работу разработчика Исполнителя.

На основании согласованных реестров мэппинга полей специалисты Исполнителя разрабатывают правила трансформации данных.

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

При этом требования к данной среде включают в себя:

· Удобство и быстрота разработки правил трансформации;

· Скорость конвертации данных. Файлы на входе и на выходе могут быть и в сотни тысяч строк!

· Возможность работать с несколькими входными файлами одновременно;

· Возможность сохранения правил трансформации в отдельные файлы.

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

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

Приведем пример объединения двух исходных xls -файлов Сотрудники. xls

и Операции. xls со страницами:

Списания

и Поступления :

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

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

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

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

Рис. 3

2.Запрос на языке 1С - основной запрос, реализующий алгоритм мэппинга полей. А также: обогащение загружаемых данных данными из базы 1С, перегруппирование, объединение с результатами запросов к другим исходным xls -файлам и пр.

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

Для примера здесь реализуется добавление строки «ИТОГО» по колонкам сумм.

4.Запись итогового набора данных в xls -файл.

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

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

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

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

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

· ошибки конвертации, ошибки загрузки данных

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

· по итогам тестовых миграций составляют/актуализируют план итоговой миграции

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

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

· Совпадения итоговых сумм по остаткам, по документам;

· Количественные совпадения, например количество ОС;

· Корректность заполнения отдельных выборочных сущностей;

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

Например:

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

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

· Ссылочная целостность;

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

· В целом, проверки обязательной заполненности полей;

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

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

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

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

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

Заключение

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

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

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

Как это бывает

Этот сценарий регулярно повторяется в том или ином виде по всему миру и в любой отрасли. С быстрыми темпами совершенствования технологий, усилением конкурентного давления, приводит к тому, что многие компании постоянно оценивают их PLM-решения и проводят улучшения. Решение может быть вызвано признанием того, что текущее решение, или, чаще, его техническое обслуживание, либо использование нескольких систем, не устраивают руководство компании. Кроме того, есть еще один общий мотив - последствия приобретений компании и осознание того, что консолидация их различных PLM решений является оправданным. Еще один сценарий – необходимость массивной перенастройки текущей платформы. Независимо от причин изменений, эффективное выполнение изменений будет зависеть от успешной миграции существующих данных на новую платформу.

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

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

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

Пример решения

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

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

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

Для получения более детальной информации об инструментах и услугах PRION рекомендую обратиться на сайт

Миграция данных

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

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

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

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

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

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

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

Миграция облака

Миграция базы данных

Миграция приложений

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

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

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

УЗНАТЬ БОЛЬШЕ О ДРУГИХ УСЛУГАХ:

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

Миграция пользователей и рабочих станций в единую структуру Active Directory реализуется с сохранением существующих прав доступа.

Варианты модернизации

Существует два основных варианта модернизации доменной инфраструктуры [ 4 ] :

• Обновление доменов. Данный способ является наиболее распространенным и простым для реализации при миграции доменов. Этот способ позволяет сохранить текущую структуру доменов, настройки системы, структуру пользователей и групп. Обновление домена (in-place обновление) включает перевод контроллеров существующего домена в создаваемый домен .
• Реструктуризация доменов. Данный способ позволяет изменить существующую структуру доменов, объединить домены или преобразовать домены в организационные подразделения.

Помимо указанных выше вариантов, существует также смешанный вариант, основанный на них, - обновление доменов с их последующей реструктуризацией [ 13 ] .

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

Критерии выбора пути перехода

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

Рассмотрим основные критерии, которые используются при выборе наиболее подходящего пути перехода [ 13 ] , приведенные в таблицах 12.1 , 12.2 , 12.3 , 12.4 , 12.5 , 12.6 .

• Критерий 1. Удовлетворенность имеющейся моделью существующего домена . Таблица 12.1. Выбор пути перехода по критерию 1

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

• Критерий 2. Степень риска при переходе к новой модели домена. Таблица 12.2. Выбор пути перехода по критерию 2

  Путь перехода	Соответствие критерию
  Обновление домена	Обновление домена представляет собой метод с минимальным риском. Процесс модернизации контроллера домена выполняется автоматически, следовательно, без взаимодействия с пользователем возможностей для ошибок возникает немного. Методология восстановления после сбоя при обновлении домена также относительно проста: если обновление прошло неудачно, необходимо выключить основной контроллер домена ( PDC ), назначить любой резервный контроллер домена ( BDC ), имеющий свежие данные, на роль PDC , и начать процедуру снова
  Реструктуризация домена	Реструктуризация домена представляет собой путь с более высоким риском, чем обновление домена. Надо выполнить большее количество задач, и поэтому многие процессы могут идти не так как надо. В результате растет недовольство пользователей, которые не могут войти в систему, обратиться к необходимым ресурсам или получить доступ к своим почтовым ящикам

• Критерий 3. Время выполнения перехода 1График времени перехода не является решающим фактором при выборе пути перехода, тем не менее он может быть определяющим для небольших организаций с ограниченными ресурсами. . Таблица 12.3. Выбор пути перехода по критерию 3

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

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

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

• Критерий 5. Наличие ресурсов для выполнения перехода. Таблица 12.5. Выбор пути перехода по критерию 5

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

• Критерий 6. Бюджет проекта перехода. Таблица 12.6. Выбор пути перехода по критерию 5

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

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

Данный путь перехода к Active Directory позволит получить немедленную выгоду (делегирование администрирования, групповые политики , публикация приложений и многое другое), а также долговременную выгоду от реструктуризации домена (меньшее количество доменов с увеличенным объемом домена, проект домена в соответствии с деловыми и организационными целями компании).

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http :// www . allbest . ru /

Введение

1. Миграция данных в проектах внедрения КИС

1.1 Цели и стратегия процесса миграции данных в проектах внедрения ИС

1.2 Этапы процесса миграции данных в проектах внедрения ИС

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

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

2. Анализ проектного опыта проведения миграции данных

2.1 Краткая характеристика проекта внедрения ИС

2.2 Выявленные проблемы при разработке плана работ и коммуникаций на этапе миграции данных

2.3 Выявленные проблемы при разработке требований к выгрузке из системы-источника

2.4 Выявленные проблемы документирования требований к миграции данных

2.5 Выявленные проблемы при тестировании загруженных данных в систему-приемник

3. Методика организации проведения миграции данных

3.1 Последовательность шагов для организации миграции данных

3.2 Оценка применения разработанной методики организации и проведения миграции данных

Заключение

Список использованных источников

Приложения

Введение

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

· Заинтересованность в качестве результата проекта;

· Направленность проектов на оптимизацию существующих бизнес-процессов, в том числе за счет совершенствования существующих средств автоматизации;

· Повышенное внимание заказчика к качеству управления проектом внедрения ИС.

Еще одним поводом для исследования являются показатели качества осуществленных проектов. По данным аналитического издания PCWeek неудачными оказываются до 75% всех ИТ-проектов.

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

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

При рассмотрении аналитических материалов по вопросам миграции данных, становится очевидным следующее существующее противоречие: разрабатываются частные программные решения и методические материалы в области миграции данных, но в то же время отсутствует общий подход к разработке требований к процессу миграции. Существует целый ряд практических наработок ведущих мировых вендоров программного обеспечения, например, IBM Best Practices или Oracle White paper, однако отсутствует обобщенный подход к организации миграции данных, который бы учитывал многообразие особенностей заказчиков и проектов. Соответственно, можно сделать предположение о том, что предложенная проблема исследования является недостаточно изученной.

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

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

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

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

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

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

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

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

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

5. Разработка методики организации процесса миграции данных, которые позволят устранить выявленные проблемы бизнеса на всех этапах миграции (планирование, сбор требований, проектирование, реализация, тестирование);

6. Оценка разработанных подходов и методов организации и проведения миграции данных.

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

В качестве теоретической базы для исследования используются методология разработки требований, сформулированная К. Вигерсом в книге «Разработка требований к программному обеспечению» , а также основные принципы методологии MSF, методы решения проектных задач этапа миграции данных, изложенные в White Paper вендоров ПО IBM , Oracle , Microsoft .

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

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

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

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

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

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

1. Миграция данных в проектах внедрения КИС

1.1 Цели и стратегия процесса миграции данных в проектах внедрения ИС

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

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

Наличие этапа миграции данных в проектах внедрения КИС определяется соответствующими бизнес-требованиями. Необходимость мигрировать данные возникает при решении одного из следующих случаев:

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

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

- Изменение ИТ-инфраструктуры при использовании текущих КИС. Здесь речь идет о необходимости миграции данных из разрозненных систем при создании общего корпоративного хранилища данных (data warehouse) для хранения данных из корпоративных приложений.

При решении перечисленных выше задач необходимо определить стратегию миграции, руководствуясь принципами которой, будут проводиться работы по миграции данных. Эксперты Oracle определяют два типа стратегий: стратегия «большого взрыва» (big bang) и стратегия плавной миграции (trickle migration).

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

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

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

1. Риски составления технической спецификации

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

2. Риски тестирования

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

3. Риски процесса получения и загрузки данных

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

4. Риски размещения данных в целевой системе

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

5. Риски, связанные с работой проектной команды

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

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

1.2 Этапы процесса миграции данных в проектах внедрения ИС

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

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

Жизненный цикл процесса миграции начинается после формирования стратегии и оценки рисков этапа миграции данных. Схема процесса миграции представлена на диаграмме процесса.

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

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

Этап сбора требований к данным для миграции, как правило, очень тесно взаимосвязан со следующим этапом - разработки алгоритмов переноса данных из системы-источника в целевую систему. На этапе проектирования аналитиками создаются подробные спецификации с описанием типов данных системы-источника и их взаимосвязей с типами данных целевой системы. В таких спецификациях описывается структура данных для миграции, их объемы, источник, назначение. Спецификация является источником для постановки задач разработчику, который будет проектировать и разрабатывать специализированное ПО для переноса данных. На этапе проектирования проводится анализ существующей архитектуры данных в системе-источнике - анализ «as is» и разработка архитектуры данных в целевой системе - «to be». При анализе существующей архитектуры данных выявляются и учитываются все ограничения и ИТ-инфраструктуре, а также их влияние на работу целевой системы с мигрированными данными. Выходными артефактами анализа архитектуры данных могут являться такие документы, как логические модели данных (ER-диаграммы, модели баз данных), словари и справочники с детальным описанием каждого элемента и его атрибутов, описание бизнес-правил работы с данными, сведения о системах, взаимодействующих с системой-источником при информационном обмене и интеграции.

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

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

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

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

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

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

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

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

Документ о рамках миграции данных;

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

План коммуникаций на этапе миграции.

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

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

Планирование и обозначение рамок миграции данных;

Бизнес-анализ и документирование требований;

Выбор, настройка или проектирование и разработка специализированного ПО;

Перенос данных;

Валидация мигрированных данных;

Опытная эксплуатация;

Пост-миграционные работы по очистке и тестированию;

Согласование результатов миграции, оценка и закрытие этапа проекта внедрения.

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

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

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

Системный аналитик - управление программой, удовлетворение потребителя;

Менеджер по разработке - управление программой, управление продуктом, управление выпуском;

Разработчик - разработка алгоритмов или специализированного ПО для переноса данных в целевую Систему, специализированного ПО (при необходимости);

Тестировщик - тестирование, управление выпуском.

Для того чтобы наглядно продемонстрировать участие привлеченных человеческих ресурсов в мероприятиях процесса миграции данных составим матрицу RACI - приведена в приложении 1 к работе (см. Приложение 1 - Матрица RACI для работ по миграции данных).

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

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

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

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

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

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

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

Вигерс предлагает использование ER-диаграмм (диаграмма «сущность-связь») для определения логической структуры предметной области. Диаграмма «сущность-связь» используется для построения модели данных предметной области. Логическая структура данных (концептуальная модель данных - КМД) позволяет описать предметную область работы системы в терминах объектов данных (сущностей).

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

Помимо диаграмм «сущность-связь» в процессе выявления требований к миграции данных может использоваться другой инструмент моделирования - диаграмма смены состояний или диаграмма перехода состояний. Диаграмма перехода состояний позволяет получить точное, полное и ясное представление о механизме с конечным числом состояний. Диаграмма перехода состояний является частью подхода к моделированию - UML (unified modelling language) и позволяет наглядно представить жизненные циклы объектов данных. Переход в каждую следующую стадию жизненного цикла определяется определенным набором бизнес-правил. При разработке такой модели в ходе разработки функциональных требований к проектируемой информационной системе необходимо проводить сравнительный анализ такой модели с аналогичной моделью для эксплуатируемой системы. При модернизации ИС некоторые состояния объектов данных могут быть изменены или исключены, могут быть изменены правила смены состояний. Такие случаи должны быть учтены при разработке требований к миграции для того, чтобы корректно определить в каком состоянии объекты данных должны быть перенесены в систему-приемник. Помимо этого, в требованиях к миграции данных необходимо учесть логические несоответствия, которые могут возникнуть из-за модернизации правил смены состояний. Например, переход объекта данных в следующее состояние может зависеть от заполнения или значения какого-либо атрибута сущности. При разработке требований к системе-приемнику атрибутный состав сущностей может быть изменен таким образом, что данный атрибут будет исключен. В таком случае смена состояний для мигрированной сущности будет невозможна. Соответственно, в работе функциональности системы-приемника возникнут сбои и ошибки. Во избежание таких ошибок каждый подобный случай изменения атрибутного состава должен быть выявлен, а в требованиях к миграции данных должна быть отражена логическая проверка или правило обработки такой ситуации. Пример разработанной диаграммы состояний для одной из сущностей в системе-приемнике приведен в приложении 3 к работе (см. Приложение 3 - Примеры схем жизненного цикла сущностей в системе-источнике).

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

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

1. Что является источником данных: корпоративное приложение, система или источники за пределами организации-заказчика?

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

3. Каковы требования к данным в целевой системе? В каких процессах новой системы будут использоваться эти данные? Позволяет ли структура данных корректно работать с ними в целевой ИС (возможно ли соотнести структуру мигрируемых данных и целевую модель данных)? Присутствуют ли в структуре данных поля и типы, которые невозможно заполнить в целевой структуре и - наоборот?

4. Каково качество данных? Соответствует ли текущий уровень качества данных уровню, необходимому для функционирования целевой системы? Есть ли критические ошибки (например, незаполненные обязательные поля, несоответствие типов данных в системе-источнике и системе-приемнике). Существует ли необходимость в разработке процедур по улучшению качества данных до начала процесса переноса данных?

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

6. Оценка критичности ошибок при переносе данных в целевую систему. Будут ли эти данные использоваться в пользовательском интерфейсе или достаточно произвести валидацию на уровне БД?

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

8. Каковы бизнес-правила работы с выбранными данными?

9. Кто является владельцем данных (контента, документов, изображений) и кто является ответственным за сохранность и качество выбранных данных?

10. Какие ограничения системы-источника отражаются на структуре данных, формах хранения и работы с данными? Сохранятся ли данные ограничения при работе с данными в целевой системе?

11. Существует ли необходимость в поддержке «онлайн» миграции данных?

12. Будут ли вноситься изменения в мигрируемые данные в течение процесса миграции? Существует ли необходимость в итеративном процессе выгрузки и загрузки данных?

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

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

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

Инструментом для отслеживания трассируемости требований по Вигерсу может являться матрица трассируемости требований. С помощью матрицы трассируемости можно наглядно представить взаимосвязи между требованиями к разрабатываемому ПО.

В приложении 2 к работе (Приложение 2 - Пример трассировки требований к миграции данных) представлен пример - фрагмент составленной матрицы трассируемости требований к миграции данных.

В приведенном фрагменте матрицы представлены различные типы пользовательских потребностей:

· Нефункциональное требование к способу проведения миграции;

· Требования непосредственно к функциям утилиты миграции данных;

· Бизнес-требование к функциональности проектируемой системы, связанное с функциональными требованиями к утилите миграции.

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

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

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

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

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

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

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

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

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

2. Анализ проектного опыта проведения миграции данных

2.1 Краткая характеристика проекта внедрения ИС

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

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

Для того чтобы подробнее описать профиль организации-заказчика, необходимо ввести несколько понятий. «Заявителем» или «публичным пользователем ИС» является лицо, обратившееся за оказанием государственной услуги. «Объектом данных» будем называть одну из сущностей или артефактов предметной области деятельности организации-заказчика. «Системой-приемником» будем называть внедряемую корпоративную информационную систему, относящуюся к классу ECM. Заказчик эксплуатирует две отдельных информационных системы, не интегрированных между собой, для хранения контента и автоматизации основного бизнес-процесса. Эти системы будут являться источниками данных - «системами-источниками» для процесса миграции данных во внедряемую систему. Первая из двух существующих систем разработана на платформе IBM Lotus Notes и предназначена для автоматизации бизнес-процесса в одном из функциональных подразделений заказчика. Вторая система была разработана сотрудниками заказчика самостоятельно и предназначена для автоматизации бизнес-процессов в других бизнес-подразделениях и хранения документов в электронном виде, сбора и хранения отчетной информации по бизнес-процессам организации.

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

Функциональный заказчик несет ответственность за качественный результат проекта;

Нефункциональный заказчик несет ответственность за финансовый результат проекта.

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

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

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

2.2 Выявленные проблемы при разработке плана работ и коммуникаций на этапе миграции данных

При разработке плана работ на этапе миграции данных менеджмент проекта опирался на модель проектной группы MSF, а также использовал в качестве инструмента распределения ответственности матрицу RACI. Анализ такого подхода был проведен выше, в Главе 1.

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

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

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

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

1) Некорректное планирование плана коммуникации с сотрудниками заказчика;

2) Некорректное планирование работ в ИСР;

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

Органы исполнительной власти регионов РФ обязаны хранить исторические данные (архивы) в течение сроков, установленных ФЗ . Таким образом, требования к составу выгрузки данных из систем-источников определяются в соответствии с регламентом хранения данных, который, в свою очередь, ссылается на федеральный закон. Помимо требований к составу выгрузки данных из системы-источника именно требования к временному горизонту хранения данных во многом определяют требуемый объем хранилища данных в системе-приемнике.

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

В соответствии с ФЗ организация-заказчик обязана хранить:

Проектную документацию по капитальному строительству в течение 20 лет;

Технологическую и конструкторскую документацию в течение 20 лет.

Организация-заказчик ввела в эксплуатацию существующие информационные системы в 2005 и 2000 годах, соответственно. Таким образом, в диапазон выгрузки для переноса данных в систему-приемник попадают все документы, хранящиеся в системах-источниках, а также все объекты, на которые ссылаются такие документы.

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

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

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

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

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

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

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

История работы со всеми перечисленными выше видами документации, хранимая в системе-источнике.

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

2.3 Выявленные проблемы при разработке требований к выгрузке из системы-источника

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

Подобные документы

Проектирование информационной системы "Учёт работы поликлиники": анализ программных продуктов, описание диаграмм бизнес–процесса, описание IDEF0, DFD, IDEF3 диаграмм потоков данных и документирования процессов посредством AllFusion Process Modeler r7.3.

курсовая работа , добавлен 20.08.2012


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

курсовая работа , добавлен 02.02.2014


Детализация функций системы и требования к информационной системе. Анализ категорий пользователей. Этапы внедрения автоматизированной информационной системы на предприятии. Описание таблиц базы данных. Защита данных от несанкционированного доступа.

дипломная работа , добавлен 22.07.2015


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

курсовая работа , добавлен 18.09.2013


Выбор методологии проектирования и разработка информационной системы "Расчёт зарплаты" для предприятия ОАО РТП "Авторемонтник". Архитектурное проектирование базы данных информационной системы и разработка её интерфейса. Тестирование программного модуля.

дипломная работа , добавлен 25.05.2014


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

курсовая работа , добавлен 27.04.2011


курсовая работа , добавлен 10.07.2014


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

дипломная работа , добавлен 30.11.2010


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

дипломная работа , добавлен 19.01.2017


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