Управление проектами по внедрению корпоративной информационной систем - Казаков И.В

Управление проектами по внедрению КИС

A.c.Управление стадией конструирования A.c.a. Планирование стадии внедрения

A.c.b. Определение основ ИСП стадии внедрения

A.c.c. Контроль и оценка состояния проекта на стадии конструирования A.d. Управление стадией ввода в действие

A.d.a. Планирование следующего поколения

A.d.b. Контроль и оценка состояния проекта на стадии ввода в действие

B.Создание рабочей среды

B.a. Спецификации среды на начальной стадии B.b. Базовая среда на стадии уточнения

B.b.a. Инсталляция и администрирование среды разработки B.b.b. Интеграция среды разработки и настройка инструментов B.b.c. Формирование базы данных запросов на изменение

B.c.Сопровождение среды на стадии конструирования

B.c.a. Инсталляция и администрирование среды разработки B.c.b. Сопровождение базы данных запросов на изменение

B.d. Сопровождение среды на стадии ввода в действие B.d.a. Сопровождение и администрирование среды разработки B.d.b. Сопровождение базы данных запросов на изменение B.d.c. Формирование и передача среды сопровождения

C.Управление требованиями

C.a. Разработка требований на начальной стадии C.a.a. Описание концепции

C.a.b. Моделирование вариантов использования

C.b. Определение основных требований на стадии уточнения C.b.a. Определение основ концепции

C.b.b. Моделирование основных вариантов использования C.c.Сопровождение требований на стадии конструирования C.d. Сопровождение требований на стадии ввода в действие

D.Проектирование

D.a. Создание архитектурных прототипов на начальной стадии D.b. Определение базовой архитектуры на стадии уточнения

D.b.a. Моделирование проекта архитектуры

D.b.b. Планирование и проведение демонстрации проекта D.b.c. Описание архитектуры ПО

D.c. Моделирование проекта на стадии конструирования D.c.a. Сопровождение модели проекта архитектуры D.c.b. Моделирование компонентов

D.d. Сопровождение проекта на стадии ввода в действие

E.Реализация

E.a.Создание прототипов компонентов на начальной стадии E.b. Реализация компонентов на стадии уточнения

E.b.a. Интеграция для демонстрации кодирования критичных компонентов E.c.Реализация компонентов на стадии конструирования

E.c.a. Кодирование компонентов для начальных версий и их автономное тестирование

E.c.b. Кодирование компонентов для альфа-версии и их автономное тестирование

E.c.c. Кодирование компонентов для бета-версии и их автономное тестирование

E.d. Сопровождение компонентов

E.e.Сопровождение компонентов на стадии ввода в действие

31

Управление проектами по внедрению КИС

F.Оценка

F.a.Планирование оценок на начальной стадии F.b.Оценки на стадии уточнения

F.b.a. Моделирование тестов

F.b.b. Реализация сценариев тестирования архитектуры F.b.c. Оценка демонстрации и описания версии

Оценки на стадии конструирования

F.b.d. Оценка начальной версии и описание версии F.b.e. Оценка альфа-версии и описание версии F.b.f. Оценка бета-версии и описание версии

F.c. Оценки на стадии ввода в действие F.d.Оценка версии продукта и описание версии

G.Внедрение

G.a. Планирование внедрения на начальной стадии G.b. Планирование внедрения на стадии уточнения G.c. Внедрение на стадии конструирования

G.c.a. Определение основ руководства пользователя G.d. Внедрение на стадии ввода в действие

G.d.a. Передача продукта пользователю

Приведенная структура должна рассматриваться как отправная точка. Ее необходимо подогнать под особенности проекта по многим направлениям.

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

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

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

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

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

32

Управление проектами по внедрению КИС

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

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

Определение последовательности работ

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

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

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

Заданы:

•перечень работ проекта и их характеристики (ИСП);

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

•взаимосвязи работ и их характеристик;

•временные ограничения;

•ограничения на условия выполнения работ;

•внешние ограничения и взаимосвязи.

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

Матрица задач и ответственности

Матрица задач и ответственности - это инструмент планирования, который предназначен для установления связи работы, определенной в структуре проекта, с организационными единицами, субподрядчиками и отдельными сотрудниками. Таким образом, с одной стороны, существует организационная структура проекта (ОСП), а с другой - работа, выполняемая в соответствии с иерархической структурой проекта (ИСП). Цель матрицы ответственности - объединение этих структур. Так как иерархическая структура проекта никогда не будет точно соответствовать ОСП, матрица обеспечивает механизм реализации основной и вспомогательной отчетности в обычной функционально организованной компании.

33

Управление проектами по внедрению КИС

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

Календарный план

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

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

1.Укрупненный календарный план проекта (календарный поэтапный мастер-план). Календарный план основных ключевых событий (контрольных точек).

2.Укрупненный календарный план инженерно-конструкторских работ.

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

4.Укрупненные календарные планы второго и последующих уровней иерархической структуры проекта (ИСП)

5.Календарный план ближайших ключевых событий (контрольных точек).

6.Диаграммы трендов проекта (тренды по стоимостям и выполнению контрольных точек).

7.Сетевой план проекта (PERT) - логическая диаграмма управления, сетевая диаграмма.

Календарные планы по задачам.

8.Календарные планы по функциональным элементам.

9.Один или несколько подробных сетевых планов (диаграмм) PERT.

10.Календарные планы создания основного продукта.

11.Календарный план эксплуатации аппаратных средств.

12.Календарные планы доставки элементов аппаратных средств. 13.Календарные планы субподрядов, заключаемых до оплаты контракта. 14.Предоставленные субподрядчиком календарные планы инженерно-

технических работ, производства и поставок/сетевые планы (диаграммы) PERT.

15.Календарный план выпуска схем, чертежей.

16.Календарные планы проведения обзоров состояния проекта, требуемых контрактами.

17.Календарный план использования имущества, предоставленного государственными органами или заказчиком.

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

19.Календарный план выпуска технических публикаций.

34

Управление проектами по внедрению КИС

20.Календарный план испытаний материалов.

21.Календарный план выполнения требований контракта.

22.Календарные планы демонстраций системы.

Укрупненный календарный план

Укрупненный календарный план - это расписание исполнения проекта, включающее лишь основные этапы и ключевые события.

Укрупненный календарный план представляет все элементы и задачи проекта на единой временной шкале.

Он должен:

•основываться на ИСП

•быть полным и охватывать все содержание проекта

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

•помогать в планировании и эффективном использовании человеческих и других ресурсов

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

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

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

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

Ниже приведены примеры объемно-календарных планов по проекту разработки информационной системы.

35

Управление проектами по внедрению КИС