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

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

 обеспечивать одинаковое понимание всеми участниками проекта;

 обеспечивать необходимую мотивацию деятельности участников проекта;

 отражать разумный уровень декомпозиции проекта;

 определять временные границы выполнения проекта;

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

выше. План проекта внедрения КИС должен охватывать все сколько-нибудь

существенные аспекты проекта внедрения.

Основные действия, выполняемые при планировании:

 структурная декомпозиция целей проекта;

 установление соответствия между подцелями, определенными в результате

декомпозиции, и работами;

 определение необходимых ресурсов;

 определение временных границ выполнения работ;

 определение места выполнения работ;

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

Target Enterprise.

1.4 Организация проекта внедрения

Иерархическая организация проекта внедрения заключается в создании

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

проекта.

Как правило, в проектную организационную структуру объединяются работники

различных подразделений существующей структуры предприятия. Также возможным

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

подбираемых соответственно требованиям проекта.

Подчинение вновь образованной проектной структуры непосредственно

высшему руководству предприятия позволяет эффективно контролировать ход

проекта, позитивно влияет на принципиальные проектные решения и, в то же время,

освобождает высшее руководство от рутинной координационной работы.

В качестве недостатков применения иерархической модели можно указать:

 возможные проблемы взаимодействия звеньев существующей

организационной структуры предприятия с проектной структурой;

 относительно невысокая эффективность использования выделенных

гуманитарных ресурсов;

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

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

несоизмеримы с затратами, свойственными данному типу модели.

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

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

интересах которого выполняется проект внедрения выступает в роли учредителя

дочерней фирмы.

Глава 2. Промышленные технологии внедрения

КИС.

2.1 Анализ стандартной проектной методики и

инструментария внедрения программного обеспечения Baan

Компания Vanenburg Business Innovation (VBI) совместно с Baan Consulting

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

обеспечения Baan. Известные методы проектного управления в сочетании с

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

Target Enterprise, где “target” от английского – цель. Цель, в данном случае – действующая

КИС предприятия (ERP-система), – достигается путём создания прототипов и

постепенного усовершенствования проектного решения. Стандартные пакетные решения с

одной стороны и устоявшиеся формы работы организации Заказчика с другой –

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

(рис. 2.1).

Рис. 2.1. Создание прототипов системы

2.2 Концепция Target Enterprise. Метод целевого управления

изменениями

В настоящее время сформировался взгляд на организацию как на сложную открытую

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

из взаимозависимых составных частей. Изменение в одной составной части системы

приводит к изменению в других её составных частях. Одной из характеристик

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

Sim1 Sim2 Sim3

определённых дисциплин, подразделений и даже предприятий, что нередко приводит к

существенной реструктуризации.

Метод целенаправленного управления проектами (GDPM), рассмотренный в

предидушей главе, положенный в основу Target Enterprise (TE), стал базовой концепцией и

философией этой проектной методики. TE обеспечивает целевое управление изменениями

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

рассматривается PSO-проект.

Важными категориями управления такими проектами становятся, прежде всего,

Концептуальный план (Milestones Plan), Результирующие пути (Result Paths), График

работ (Project Schedule), Диаграммы ответственности (Responsibility Charts).

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

GDPM и представлен анализ методики Target Enterprise.

2.2.1 TE и управление PSO-проектами

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

результирующим путям (рис. 2.2). Результирующие пути определяют направления

достижения целей проекта. Группировка событий необходима для сбалансированной

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

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

отвечать определённым требованиям:

1) план должен отражать согласованные и реалистичные границы проекта (project

scope);

2) каждое отдельное событие должно соответствовать конечной цели проекта;

3)названия событий должны формулироваться в терминах свершённых действий и

достигнутых результатов;

4) события должны распределяться равномерно на протяжении всего жизненного

цикла проекта;

5) количество событий каждой стадии проекта должно соответствовать общим

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

6) количество событий каждого результирующего пути должно соответствовать

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

результирующим путям;

7) процессы принятия решений и время, затрачиваемое на них должны отражаться в

плане;

8) описания вех должны содержать недвусмысленные критерии их достижения

Рис. 2.2. Вехи по результирующим путям

Планирование проекта осуществляется на трёх уровнях:

 корпоративном уровне;

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

 уровне рабочих групп.

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

приводится в соответствие с целями, определяется приблизительный бюджет (по

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

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

из корпоративной стратегии развития бизнеса и управления.

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

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

назначаются ответственные стороны, описывается структура отчётности и коммуникаций

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

Работы

Веха C1

People Organization

System

Веха C2

проекту.

Ответ на вопрос КАК получают с помощью планирования на уровне рабочих групп:

определяются состав и объёмы работ для каждой вехи; осуществляется распределение

обязанностей персонала по работам (поимённо); разрабатывается ролевая модель проекта,

производится оценка объёмов работ для каждого работника; детализируется критический

путь и продолжительность проекта.

Диаграмма ответственности составляется на корпоративном уровне. Субъектами

ответственности становятся группы исполнителей или подразделения, ответственность

распределяется между Исполнителем и Заказчиком проекта. При этом для каждого

события (вехи) должны быть определены ответственности типа “консультирует”,

“исполняет”, “принимает решения”, “управляет реализацией” и некоторые другие.

Диаграмма может детализироваться до уровня отдельных исполнителей. Диаграммы

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

разрабатываются совместно с планом вех и графиком работ.

График работ отражает взаимосвязи событий и трансформацию событий до уровня

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

Ганта средствами, например, MS Project. График работ должен отвечать определённым

требованиям:

1) каждая работа должна быть направлена на достижение конкретного события;

2) комплексы работ, распределённые по вехам должны качественно отличаться друг

от друга;

3) загрузка исполнителей должна согласовываться с последними;

4) загрузка по регулярным работам должна учитываться при составлении загрузки по

проектным работам;

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

6) сроки исполнения должны удовлетворять желательной продолжительности

проекта.

Вместе, Концептуальный план, Диаграммы ответственности и График работ

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

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

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

процессы контроля и исполнения.

Для проекта внедрения контроль может осуществляться на двух уровнях: уровне

команды управления проектом и уровне рабочих групп (рис. 2.3). На первом уровне

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

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

проекта, менеджеры, ответственные за достижение тех или иных вех. На втором уровне

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

ответственности. Члены рабочих групп отчитываются в проделанной работе.

Рис. 2.3. Уровни контроля проекта

Планиру-

емым

работам

Планиру-

емым ре-

зультатам

Следо-

вание

Организа-

ция работ и

исполни-телей

Организа-

ция проекта

Следо-

вание

ЧТО

осуществить

КАК

осуществить

Концептуальный план

Диагр. отв. по проекту

Графики работ

Диагр. отв. по работам

Сетевое планирование

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

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

должна проводиться заранее, но не более чем на 1 – 3 месяца вперёд. Обратная связь (от

рабочих групп к координационному совету) может осуществляться посредством

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

продвижению проекта.

2.2.3 Структурный анализ методики Target Enterprise

Структурная декомпозиция TE по основным категориям носит название Work

Breakdown Structure (WBS). В узком смысле WBS рассматривается в качестве одного из

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

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

структурой, сетевыми моделями, структурами стоимости и ресурсов. Однако в более

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

элементов проекта, ориентированных на достижение тех или иных результатов. Будем

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

TE. Итак WBS рассматриваемой методики можно представить следующим образом (рис.

2.4):

Рис. 2.4. Структура методики Target Enterprise

Жизненный цикл TE отражает последовательную смену и эксплуатацию

большинства релизов ERP-системы организации Заказчика. Внедрение новой

 Жизненный цикл

Программы

 Фазы

Проекты

 Стадии

o События

 Работы

информационной системы, как правило, означает начало нового жизненного цикла и

окончание жизненного цикла предшествующей системы. Жизненные циклы могу также

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

(слияния, поглощения или выделение отдельных звеньев организации). Здесь следует

различать понятие жизненного цикла проекта и жизненного цикла продукта. Жизненный

цикл TE подразумевает управление жизненным циклом информационной системы,

последняя является продуктом.

Следующий уровень WBS – Программа. Управление программами необходимо для

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

(проектами). Программы, как правило, тесно связаны со стратегическим планированием и

обеспечивают развитие информационных технологий. Управление программами особенно

необходимо в многозвенных организациях (холдинги, ТНК) при наличии многочисленных

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

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

Концепция программного управления помогает в таких случаях:

1) инициировать проекты в тесной связи со стратегией развития бизнеса;

2) согласовывать проекты выбора, внедрения и оптимизации (см. след. пункт Фазы);

3) координировать проект внедрения с организацией Центра компетенции Baan;

4) координировать проект внедрения с отдельными проектами вне сферы

информационных технологий (проекты реинжениринга бизнес процессов, проекты

усовершенствования логистических систем).

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

стратегии (в том числе и в сфере ИТ) и управления проектами. Они необходимы для

формирования целей проектов и служат “зонтиками” для успешной реализации последних.

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

проекты. В TE выделяются следующие фазы: Выбор (Selection) или разработка для

заказчика проектного решения на общем уровне; Консолидация (Visioning) или

формирование единого образа компании, разработка корпоративного проектного решения

для нескольких звеньев организации; Внедрение (Implementation) или действительная

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

Baan, эта фаза для многозвенного внедрения протекает по принципу “rollout”, то есть

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

Оптимизация (Optimization), период после внедрения, в течение которого компания

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

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

случае однозвенного внедрения фаза консолидации не используется.

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

фазе внедрения в случае многозвенного внедрения часто осуществляется проект пилотного

внедрения (для подтверждения и уточнения корпоративного проектного решения,

полученного на фазе консолидации), затем – один или несколько проектов

“штампованного” внедрения (rollout).

Проекты TE состоят из стадий. Переход от одной стадии к другой сопровождается

приёмкой Заказчиком формализованных промежуточных результатов. Для проектов фазы

выбора (selection) предложены следующие стадии: Ориентация (Orientation) или

определение на общем уровне состава программных приложений и выбор одной или

нескольких референтных моделей предприятия; Решение (Solution) или более детальное

оформление модели организации (допустимо “Моделирование 0” или нулевой прототип),

определение на общем уровне вариантов технического обеспечения; Соглашение

(Resolution) или определение на общем уровне проекта внедрения (принципы, подходы,

бюджет, ресурсы), подписание контрактов.

Для проектов фазы внедрения (implementation), предложены следующие стадии:

Инициализация (Initiation) – формирование организационной структуры проекта,

разработка устава проекта; Разработка предварительного проектного решения (Mapping) –

получение предварительного проектного решения, к окончанию стадии проводится

семинар с демонстрацией действия сконструированного прототипа (“Моделирование 1”);

Разработка окончательного проектного решения (Piloting) – детальная проработка и

тестирование проектного решения на базе стандартных приложений, (“Моделирование

2”); Реализация (Realization) – детальная проработка и тестирование интегрированного

проектного решения, написание программ по планам кастомизации, локализации и

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

прототипа (“Моделирование 2”); Миграция (Migration) – обеспечение эксплуатации

проектного решения (с помощью программ переноса данных, написанных на предыдущей