Швей В.И. Управление проектами информационных систем

Подождите немного. Документ загружается.

составляющие плана вех, позволяющие группировать вехи по направлениям для

достижения поставленных целей.

Можно выделить несколько факторов, влияющих на формирование

организационной структуры проекта: масштаб проекта, объёмы работ, сложность,

продолжительность, цели, риски проекта, особенности корпоративной культуры

Заказчика. Совместное действие этих факторов может предопределить количество рабочих

групп, их детализацию, постадийное развёртывание организационной структуры,

реинжиниринг структуры, особую организацию коммуникаций.

Роли, изображенные на рисунке 2.8, могут исполняться разными или одними и теми

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

равномерную загрузку и исключало пробелы в исполнении тех или иных ролей. Далее

представлено краткое описание ролей организационной структуры проекта.

Управление проектом. Руководитель проекта – лицо ответственное за реализацию всего

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

Практически все управленческие роли, которые будут представлены ниже, должны

исполняться как работниками Заказчика, так и работниками Исполнителя. В этом смысле

руководитель проекта со стороны Исполнителя считается наставником руководителя

проекта со стороны Заказчика и отвечает за достижение вех, закреплённых в диаграмме

ответственности верхнего уровня за Исполнителем. Офис проекта – обеспечивающий

элемент структуры, осуществляющий поддержку руководства проекта и проектной

команды в части планирования, администрирования, документооборота и управления

качеством. В офисе назначаются следующие роли: офис-менеджер проекта, администратор

качества, администратор ресурсов, плановик, инспектор, секретарь, администратор

документооборота.

Построение бизнес модели. Старший менеджер (СМ) по бизнес моделированию – в

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

моделированию (от Заказчика, от Исполнителя), ответственность между ними

распределяется диаграммой ответственности проекта. СМ по бизнес моделированию

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

Рис. 2.8. Взаимосвязь ролей ключевых пользователей Заказчика и

консультантов Исполнителя

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

группы вех: кастомизацию/локализацию (C); интерфейсы (I); программы миграции данных

(D). Работы необходимые для достижения вех в этих группах взаимосвязаны и требуют

схожих навыков, поэтому, как правило, объединяются, и управление ими поручается СМ

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

программист. Роль постановщика могут выполнять совместно ключевые пользователи и

консультанты.

Техническое обеспечение. Старший менеджер по техническому обеспечению

руководит работой технических консультантов.

Организационные улучшения. СМ по организационным улучшениям ответственен

за выявление, описание и контроль исполнения организационных изменений,

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

берёт на себя руководитель проекта. Управляющие – лица, работники Заказчика,

Линейный

руководитель

Оператор

Функциональный

менеджер

Бизнес аналитик

Администратор

бизнес

моделирования

Консультант по

функциональности

Роль

консультанта

Роль

ключевого

пользователя

Консолидация,

правила ведения

бизнеса

Бизнес сценарии,

основные процессы

Процедуры,

Рабочие инструкции,

Использование

данных

Организационные

аспекты

Структурная модель

предприятия

Функциональная

модель

Потоки данных,

кодирование данных

Системные

аспекты

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

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

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

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

планов тренинга и коммуникаций, а также управляет соответствующими работами в

рамках этих планов. Эту роль может выполнять руководитель проекта. Тренер

осуществляет работы, предусмотренные планами. Для понимания роли тренера

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

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

обучается консультантами Исполнителя. Второй участвует в отдельном проекте

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

правило, входящие в Центр компетенции Baan. Конечный пользователь обучается в

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

консультанты Заказчика, ключевые или местные ключевые пользователи.

Рис. 2.9. Взаимодействие проектной и функциональной организаций

Управл.

комитет

Рук-ль

прогр.

Линейные

руководители

Функцио-

нальные

менеджеры

Операторы

Функциональная

организация

Программная / проектная

организация

Координатор

проекта

Рук-ль

проекта

Коорд.

совет

Координатор

программы

Одно

звено внедрения

Множество

звеньев внедрения

Организационная структура проекта – составная часть организационной структуры

программы. Взаимосвязи организации Заказчика (функциональной организации),

элементов структуры программы и структуры проекта представлены на рисунке 2.9.

Руководитель проекта назначается совместно координатором проекта и руководителем

программы, подчинён руководителю программы. Руководитель программы назначается

координатором программы. Координатор программы – член высшего руководящего

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

представляет интересы Заказчика. По аналогии определяется и координатор проекта.

Координационный совет (КС) осуществляет взаимосвязь программы с функциональной

организацией, на уровне проектов аналогами КС выступают Управляющие комитеты (УК).

КС и УК не следует рассматривать как основные органы взаимодействия. Для успешной

реализации программ и проектов крайне важны горизонтальные связи. Вовлечение

линейных руководителей в совместную работу с членами проектной команды – ключевой

фактор успеха проекта.

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

Все документы проекта можно разбить на две категории:

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

 документы реализации проекта.

Документы реализации проекта отражают содержание проектного решения.

Согласно методу GDPM к документам управления относятся три базовых документа:

 концептуальный план;

 график работ;

 диаграммы ответственности.

Эти документы используются в зависимости от уровня контроля проекта. При этом

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

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

по внутренним документам, составляющим проектное решение (Рис. 2.10).

План вех

Спецификация

промежуточных и

конечных результатов

проекта

Диаграмма

ответственности

Организация

Администрирование

Связь с функциями

Процедуры для

взаимодействия

Приоритеты проекта

Достижение плана вех

- Список

задач

- Отчёт о

ходе работ

- Диаграм.

ответственн

ости

- Диаграм.

Ганта

Отчётность о выполнении графика работ

Уровень команды

управления проектом

Уровень

Рабочих групп

Планирование и контроль Организация и взаимодействие

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

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

документы более общего уровня.

Таблица 2.4

Группировка документов управления проектом

Название документа Примечания к группам документов

Устав проекта Описывает основные положения проекта,

изменения устава должны тщательно

прорабатываться, особенно в части затрат и

продолжительности

Миссия проекта

Масштаб проекта (на общем уровне)

Цели и результаты проекта

Допущения и условия успешной реализации

Стадии проекта

План вех

Диаграмма ответственности

Бюджет проекта (на общем уровне)

Орг. структура проекта и описание ролей

План управления рисками

Оценка рисков

Стратегия предотвращения рисков

План работ проекта Наиболее подвержен изменениям

График работ (MS Project)

Бюджет (подробно)

Органайзер проекта Содержит подробные процедуры, отражающие

то, как будет реализовываться проект

Процедуры проектного управления и контроля

Процедуры приёмки работ

Процедуры управления изменениями проекта

Процедуры документооборота

2.3 Эволюция проектного решения на фазе внедрения

Рис. 2.11. Структура проектного решения

Как уже было показано, внедрение – это одна из фаз программы Target Enterprise.

Данная фаза часто включает несколько проектов пилотного и штамповочного внедрения.

Для программ в многозвенном окружении основывается на результате работ фазы

консолидации – на корпоративном проектном решении (КПР). В процессе внедрения КПР

используется для получения локальных проектных решений (ПР) каждого звена

организации. Фазы консолидации и внедрения протекают практически одинаково, только в

проектах первой отсутствуют стадии миграции (КПР не предназначено для

непосредственного внедрения). Далее будет проанализирована структура ПР и его

эволюция в рамках фазы внедрения.

2.3.1 Структурный анализ проектного решения

Структура ПР тесно связана с концепцией результирующих путей (рис. 2.11),

Бизнес слой:

Построение

бизнес модели

Программный слой:

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

Разработка

Стандартное

ПО

Интерфейсы

Кастомизация

и локализация

Данные и

программы

переноса данных

Модель управления бизнесом

Бизнес функциональная

и процессная модель

DEM, Бизнес сценарии

Организационная модель

DEM, рабочие инструкции

Модель данных

Рабочий прототип

Организационное

обеспечение

Анализ необходимых

организационных

изменений

Реализация

организационных

изменений

Аппаратные средства

Операционные

системы

Системы управления

базами данных

Сети

Техническое обеспечение

Кадровое

обеспечение

Навыки работы в

проектной

команде

Учебные материалы

для конечных

пользователей

Осведомлённость и

мотивация

работников

компании

План тренинга

План

коммуникаций

Тренинг и

коммуникации

Техническое

обеспечение

Организационные

улучшения

названия путей написаны курсивом, каждый путь соответствует элементу ПР). Из семи

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

программой можно отнести к сфере реализации проекта, то есть, к проектному решению.

ПР изменяется по ходу реализации, если в определённый момент времени взять “срез”

достигнутых промежуточных результатов (вех) по результирующим, то совокупность этих

результатов и будет проектным решением на заданный момент времени.

Информационная система – продукт проекта внедрения – это определённая бизнес

модель в сочетании с программным и техническим обеспечением. Все три элемента

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

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

соответствии с GDPM, информационная система не в состоянии функционировать без

соответствующего организационного и кадрового обеспечения. При этом к

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

нормальной работы информационной системы изменений функциональной организации

Заказчика.

Таким образом, проектное решение = рабочий прототип системы + техническое

обеспечение + организационное обеспечение + кадровое обеспечение. Рабочий прототип

системы = бизнес модель + программное обеспечение.

Рабочий прототип (РП).

Прототип информационной системы представляет собой полную функциональную

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

обеспечение. Таким образом, прототип состоит из двух слоёв: бизнес слой

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

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

Разработка). Наличие двух слоёв позволяет объединить организационные аспекты (бизнес

процессы, например) и системные аспекты (программы Baan). Бизнес слой проецируется,

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

организацию звена внедрения (организационные аспекты).

Бизнес слой.

Представляет проектное решение с точки зрения способов ведения бизнеса, включает

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

из модели управления бизнесом; бизнес функциональной и бизнес процессной моделей

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

данных (спецификации кодирования). Основные вопросы, на которые необходимо

получить ответы: ЧТО, КАК, КЕМ и ГДЕ.

Программный слой.

Ответы вопросы проецируются на программный слой. Последний состоит из

стандартных приложений (к ним может относиться также ПО третьих фирм, но в общем

случае это программы, отчёты и формы Baan с необходимой персонализацией);

кастомизации и локализации; интерфейсов (связей с предшествующими ИСУ); данных и

программ переноса данных.

Техническое обеспечение (ТО).

Результат работы в этом направлении – решение по ТО, необходимому для

функционирования бизнес модели. ТО включает аппаратные средства; операционные

системы; СУБД; сети и сетевое оборудование. По ходу проекта элементы ТО выбираются,

устанавливаются, настраиваются и тестируются.

Организационное обеспечение (ОО).

РП и ТО вместе представляют собой будущую ИСУ предприятия. Однако для

подготовки существующей системы управления к эксплуатации новой информационной

системы необходимы изменения (организационные). На основе процессных и ролевых

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

в зависимости от типа программной стратегии организационные улучшения могут

реализовываться или нет. Часто улучшения инициируются в рамках программы Target

Enterprise, но до проекта внедрения (первая типовая стратегия). В любом случае изменения

позволяют “сдвинуть” навстречу друг другу конфигурацию внедряемой информационной

системы и существующую систему управления. Примерами организационных изменений

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

новых рабочих инструкций, пересмотр политики компании, улучшение описаний рабочих

мест.