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

Лейф Поулсен для 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 Поулсен отвечает за развитие технологий, методов и компетенций в области промышленной автоматизации и ИТ, и работает как старший бизнес-консультант.

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

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

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

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

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

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

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

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

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

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

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

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

План работ по миграции определяет набор задач и ответственных за их выполнение, распределенных с помощью матрицы 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 - Журнал тестирования результатов миграции).

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

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

В большинстве случаев миграция данных требует индивидуального подхода и определённого опыта.

• Необходимо заранее заранее определить стратегию миграции данных. Слабое понимание процесса и не достаток опыта не повод относиться халатно к миграции данных;
• Обязательно должен быть составлен план миграции данных и назначены ответственные сотрудникам и ключевые пользователи;
• Определить какие основные данные (материалы, контрагенты, банки, и пр.) и какие транзакционнные данные (заказы, открытые позиции и пр.) будет участвовать в миграции данных;
• Определить периоды и объемы данных;
• Подготовить регламенты и методики миграции данных;
• Нормализация и структуризация данных. Так же очень важный шаг при миграции данных. Не бывает такого, чтобы было слишком рано начинать очистку данных от мусора (дубли, не полные и не однозначные записи). Пропуская этот шаг помните, что мусорные данные приведут к проблемам в эксплуатации SAP и могут стоить компаниями намного дороже, чем во время сделанная очистка данных;
• При миграции данных должны быть обязательно разработаны понятные шаблоны сбора и загрузки данных. Это так же ответственный шаг, ключевые пользователи должны однозначно понимать что и как заполнять в шаблоне;
• Разработать средства загрузки данных. Средства должны быть понятны и удобны для сотрудников НСИ, а так же содержать проверки и защиту от человеческого фактора. А так же загрузчики данных должны уметь быстро загружать данные. За частую процесс загрузки готовых шаблонов с данными занимает не более 5 дней;
• Контроль процесса миграции данных должен производиться на всех этапах, как во время тестовой миграции данных, так во время пилотного запуска и продуктивной загрузки данных.
• Заключительный этап, после продуктивной миграции данных, это проверка качества загруженных данных. Помните, что исправить все проще на ранних стадиях. По этому только убедившись в 100% качестве загруженных данных следует начинать продуктивную эксплуатацию системы.

Мы специализируемся на комплексном подходе к миграции основных данных и справочников НСИ.

• Составим план миграции, включающий ответственных и очередность загрузки справочников;
• Определим вместе с вами объемы и сроки миграции данных;
• Напишем методики и регламенты миграции данных;
• Проведем нормализацию, консолидацию и классификацию данных;
• Подготовим шаблоны для миграции данных, с понятным описанием их заполнения;
• Напишем загрузчики для миграции данных. Мы разрабатываем загрузчики стандартными средствами SAP, в частности LSMW, гарантирует качественную и стабильную загрузку данных;
• Проведем тестовую и продуктивную миграцию данных;
• Проверим качество загруженных в систему данных.

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

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

создание рабочей группы (кто делает)

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

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

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

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

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

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

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

исследование (что есть)

Первым этапом должен быть аудит – описание существующей (унаследованной) системы.

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

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

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

Список выявленных рисков, связанных с использованием нелицензионного ПО;

Подсчет стоимости приобретения лицензий на установленное ПО;

Подсчет стоимости удаления нелицензионного и установки лицензионного ПО;

Определение целесообразности дальнейшего использования ПО;

Список выявленных рисков, связанных с использованием ПО;

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

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

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

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

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

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

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

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

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

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

Exponent Navigator

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

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

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

Автоматический сбор информации о компьютерах по сети;

Определение установленного оборудования;

Определение установленных программ;

Определение файловых характеристик;

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

Подготовка печатных отчетов;

Экспорт данных в MS Excel;

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

В бесплатном варианте программы существует ограничение – учет до 25 компьютеров; стоимость лицензии составляет $1 за 1 компьютер.

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

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

Существует масса литературы, в том числе русскоязычной, о Linux, в которой описано преимущество этой платформы с технологической точки зрения. Однако, все эти преимущества имеют значение вместе с главным вопросом – существованием широкого спектра прикладного ПО разного направления. Достаточно давно и широко распространен миф о том, что под платформу Linux существует ограниченное количество прикладного программного обеспечения для корпоративного пользования, в том числе офисной автоматизации. В подавляющем большинстве эти мифы создаются и подпитываются создателями и продавцами проприетарного ПО и имеют мало общего с действительностью. Развенчание данного мифа не является главной целью данной книги. Тем не менее, стоит заметить, что, к примеру, широта прикладного ПО является абсолютным фантомом с учетом сложившихся исторически стандартов на обмен документов. Так, к примеру, фактическим стандартом офисного редактора является Microsoft Office, редактором растровой графики – Adobe Photosop, а в качестве векторной графики черезвычайно распространен Corel Draw.

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

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

Однако, в данный момент документ только создается и информацию можно найти в разных источниках. Невозможно пройти мимо материалов Valery V. Kachurov, Несов Артем “Аналоги Windows-программ в Linux – таблица соответствий.” (http://linuxshop.ru/linuxbegin/win-lin-soft/). Этот ресурс содержит массу ценной информации. К сожалению авторы, кажется, забросили этот труд. Данный раздел сайта регулярно недоступен, но копию таблицы можно найти по адресу http://www.blif.net/modules.php?name=LinWin. Можно посоветовать ресурсы Open Source Applications Foundation
(http://www.osafoundation.org/), особенно http://www.osafoundation.org/desktop-linux-overview.pdf.

Результатом являются:

Создания прототипа рабочих станций;

Подсчет стоимости лицензий на предлагаемое ПО;

Обучения пользователей;

Создание примерного календарного плана внедрения;

Список рисков при внедрении свободного ПО;

Поддержки свободных решений;

Подсчет экономической эффективности новой системы на срок до пяти лет.

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

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

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

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

Экспериментальный этап особенно востребован:

Если не была доказана возможность миграции пользователей от унаследованной системы к новой системе;

Если есть пользовательский скептицизм, который будет способен затормозить процесс миграции;

Организация испытывает недостаток корпоративной культуры (что, к сожалению распространено на территории СНГ);

Если есть ограниченные ресурсы для крупномасштабной миграции;

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

Если унаследованные проприетарные системы стремительно эволюционировали как в - техническом плане, так и в снижении стоимости;

Не выяснен полностью экономический эффект миграции.

Чтобы преуспеть, пилотный проект:

Не должен относиться к критическому участку бизнеса;

Должен быть достаточно важен для бизнеса;

Не должен требовать черезмерного ресурса людей, которые уже ограничены во времени;

Должен иметь существенную группу поддержки;

Должна быть обеспечена обратная связь с пользователями (системы Help Desk);

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

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

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

Описание специфических настроек пользователя:

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

Переноса данных из наследованной системы в новую;

Обучения пользователей;

Подсчет стоимости внедрения ПО;

Поддержки свободных решений.

планирование (что и как)

1. Создание плана миграции. План миграции должен отвечать на вопросы:

Описание фаз построения системы;

Определение потребностей поддержки;

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

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

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

План должен отвечать на следующий вопросов:

В какой степени и какими этапами система должна быть установлена и развернута, чтобы максимально удовлетворять потребностям пользователей?

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

Каково будет воздействие и риск использования системы на каждом этапе приращения?

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

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

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

Какого обучения и помощи в эксплуатации пользователи будут требовать?

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

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

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

Возможна ли поддержка свободного решения ИТ подразделением организации или лучшим вариантом будет аутсорсинг?

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

Система сообщения неприятностей;

Службы технической помощи для новых систем;

Техническая помощь пользователям, мигрирующим к новым системы;

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

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

Возможность испытания использования новых систем;

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

Преодоления текущих эксплуатационных проблем.

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

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

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

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

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

Установить стимулы к действиям полностью перейти на новую свободную систему и устранить зависимости от унаследованных систем;

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

Архивирование данных унаследованных систем и их хранение.

миграция (делаем)

Все, что остается на последнем этапе – работать согласно плану.

Активно управляйте и контролируйте процессы миграции:

Установите критерии измерения и отслеживайте этапы миграции и затраты ресурсов на миграцию;

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

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

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

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

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

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

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

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

От системы отдела к уровню предприятия

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

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

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

План действий

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

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

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

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

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