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

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

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

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

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

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

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

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

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

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

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

• — проектную документацию по капитальному строительству в течение 20 лет;
• — технологическую и конструкторскую документацию в течение 20 лет.

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

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

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

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

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

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

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