БИБЛИОТЕКА ПМСОФТ УДК 658.512.012(083.
84)
В.В. Трофимов, А..В. Цветков,
Д.А. Евсеев, В.С. Карпова
PRIMAVERA В УПРАВЛЕНИИ
ПРОЕКТАМИ
Практическое пособие
Москва
2006
ББК 65.290-2
Т50
Трофимов В.В., Цветков А.В., Евсеев Д.А., Карпова В.С. Primavera в
управлении проектами. Практическое пособие. /Под ред. проф.
В.В.Трофимова М.: Изд-во ЗАО «ПМСОФТ», 2006. — 248 с.
Предлагаемая вашему вниманию книга представляет собой практическое пособие по вне-
дрению и сопровождению информационной системы управления проектами, реализованной на
базе программного продукта Primavera. Подходы и решения, предлагаемые в этой книге, с одной
стороны, базируются на традиционной методике управления проектами, изложенной в Project
Management Body of Knowledge (PMBoK) и Organizational Project Management Maturity Model
(OPMMM) Американского института управления проектами (PMI), а с другой стороны, на прак-
тическом опыте авторов, полученном при внедрении и сопровождении информационной системы
управления проектами в различных компаниях. Изложение методического материала ведется в
соответствии с фазами жизненного цикла проекта, а изучение основных приемов применения про-
граммного продукта Primavera ведется на базе реальных примеров, с которыми чаще всего сталки-
вается управляющий проектом, что существенно облегчает понимание и усвоение материала.
Книга предназначена для специалистов и руководителей, занимающимся внедрением ме-
тодов проектного управления, отвечающих за сопровождение информационной системы управле-
ния проектами в своей организации. Она также будет полезна студентам, обучающимся по эконо-
мическим специальностям и изучающих дисциплину «Управление проектами», а также аспиран-
там, желающим углубить свои знания и приобрести навыки по применению Primavera в области
управления проектами любой организации.
Рецензенты: д.э.н., профессор С.Г. Светуньков
д.э.н., профессор А.Б. Курицкий
Все вопросы направляйте в ЗАО «ПМСОФТ»
119991, Россия, Москва, 2й Спасоналивковский пер., д.6
Тел.: (495) 232-1100
Факс: (495) 238-1098
www.pmsoft.ru
ISBN 5-9900281-8-0
© Издательство ЗАО «ПМСОФТ», 2006
2
 Содержание
Введение................................................................................................. 6
1. Методология управления проектами компании .................................. 7
1.1. Методы построения проектных моделей компании ..................... 7
1.2. Управление проектами и стратегии компании........................... 11
1.2.1. Компания как объект стратегического управления............. 11
1.2.2. Формирование бизнес-модели компании............................ 15
1.3. Модель организационной зрелости управления проектами ....... 17
1.4. Информационная система управления проектами как инструмент
реализации стратегий компании ................................................ 20
1.5. Проектно-ориентированный бизнес........................................... 25
1.5.1. Организационная структура управления проектами........... 26
1.5.2. Документационное обеспечение управления проектами .... 29
2. Процессы управления проектами компании ..................................... 33
3. Карта соответствия функций Primavera и процессов PMBOK........... 37
3.1. Группа процессов Инициации ................................................... 37
3.2. Группа процессов Планирования............................................... 38
3.3. Группа процессов Исполнения .................................................. 50
3.4. Группа процессов Мониторинга и управления .......................... 53
3.5. Группа процессов Закрытия....................................................... 59
4. Состав информационной системы .................................................... 60
4.1. Функциональные подсистемы информационных систем
управления проектами............................................................... 60
4.1.1. Принципы формирования функциональных подсистем. .... 60
4.1.2. Обзор программных средств управления проектами .......... 61
4.1.3. Обзор программных модулей Primavera ............................. 66
4.2. Обеспечивающие подсистемы информационных систем
управления проектами............................................................... 71
4.3. Жизненный цикл информационной системы управления
проектами. ................................................................................. 75
5. Архитектура информационной системы управления проектами,
построенной на базе Primavera ............................................................. 79
5.1. Методология концентрического управления проектами........... 79
5.2. Глобальные проектные данные.................................................. 81
5.2.1. Структура проектов предприятия ....................................... 82
5.2.2. Организационная структура компании ............................... 85
5.2.3. Структура ресурсов ............................................................ 88
5.2.4. Структура ролей ................................................................. 96
5.2.5. Календари........................................................................... 99
5.2.6. Структуры кодирования ................................................... 100
5.3. Особенности пользовательского интерфейса........................... 103
3 4
5.3.1. Использование и настройка стартового окна .................... 104
5.3.2. Использование и настройка макетов................................. 106
5.3.3. Использование форм ........................................................ 108
5.4. Экспорт и импорт данных........................................................ 112
6. Ведение проекта в Primavera........................................................... 121
6.1. Фаза «Инициация»................................................................... 121
6.2. Фаза «Планирование».............................................................. 126
6.2.1. Создание и корректировка проектных календарей ........... 127
6.2.2. Создание проекта.............................................................. 130
6.2.3. Формирование уровней декомпозиции работ ................... 141
6.2.4. Назначение ответственных на уровни WBS ..................... 142
6.2.5. Ввод и корректировка информации по работам проекта .. 143
6.2.6. Назначение и удаление зависимостей между работами.... 146
6.2.7. Назначение ресурсов на работы проекта .......................... 148
6.2.8. Назначение и удаление расходов на работы проекта ........ 150
6.2.9. Назначение кодов и заметок на работы проекта ............... 152
6.2.10. Расчет расписания проекта ............................................. 156
6.2.11. Анализ загрузки ресурсов и устранение ресурсных
конфликтов ....................................................................... 159
6.2.12. Формирование базового плана проекта .......................... 162
6.2.13. Создание альтернативных сценариев графика проекта ... 164
6.3. Фаза «Исполнение» ................................................................. 166
6.3.1. Ввод и применение фактических данных по работам проекта
.......................................................................................... 166
6.3.2. Ведение электронного дела проекта ................................. 174
6.4. Фаза «Мониторинг и Управление» .......................................... 177
6.4.1. Контроль отклонений по WBS.......................................... 178
6.4.2. Контроль отклонений графика работ................................ 179
6.4.3. Контроль отклонений по ресурсам и расходам................. 181
6.4.4. Контроль отклонений с использованием отчетов ............. 181
6.5. Фаза «Завершение».................................................................. 182
7. Анализ, отображение и печать информации по проекту ................. 185
7.1. Отображение данных проекта.................................................. 185
7.1.1. Сортировка данных .......................................................... 185
7.1.2. Фильтрация данных.......................................................... 186
7.1.3. Группировка данных ........................................................ 189
7.2. Настройка и печать временного графика проекта .................... 191
7.2.1. Настройка вида линий временного графика проекта ........ 192
7.2.2. Отображение целевого (базового) плана проекта ............. 194
7.2.3. Настройка линий зависимостей ........................................ 195
7.2.4. Настройка надписей на линиях......................................... 196
7.2.5. Настройка масштаба временной шкалы............................ 198
 7.2.6. Печать графика проекта.................................................... 200
7.3. Формирование и печать отчетов. ............................................. 207
7.3.1. Просмотр отчета ............................................................... 208
7.3.2. Просмотр группы отчетов ................................................ 209
7.3.3. Создание проектного отчета ............................................. 211
7.3.4. Изменение проектного отчета........................................... 215
7.3.5. Печать отчета ................................................................... 215
7.4. Получение обобщенных данных.............................................. 218
7.4.1. Обобщенные данные по работам проекта......................... 218
7.4.2. Обобщенные данные по уровням WBS............................. 221
7.4.3. Обобщенные данные по проекту в целом ......................... 223
7.4.4. Суммирование .................................................................. 225
Контрольные вопросы и задания ........................................................ 226
Приложения........................................................................................ 227
Основная литература .......................................................................... 246
Дополнительная литература ............................................................... 246

5
Введение
Предлагаемая вашему вниманию книга представляет собой практическое
пособие по внедрению и сопровождению информационной системы управ-
ления проектами (ИСУП), реализуемой на базе программного продукта Pri-
mavera и традиционных методик: Project Management Body of Knowledge
(PMBoK) и Organizational Project Management Maturity Model (OPM3) Амери-
канского института управления проектами (PMI), и является дальнейшим
развитием материала, изложенного в предыдущей версии книги1. Изучение
основных приемов применения программного продукта Primavera ведется на
базе реальных примеров, с которыми чаще всего сталкивается управляющий
проектом, что существенно облегчает понимание и усвоение материала.
В первой главе излагается методология управления проектами компа-
нии. На базе системного подхода строится проектная модель компании, пока-
зывается место управления проектами в стратегическом управлении компа-
нией, затем компания рассматривается как объект стратегического управле-
ния, формируется ее бизнес-модель и сопоставляется с моделью организаци-
онной зрелости управления проектами. Информационная система управления
проектами рассматривается как инструмент реализации выбранных стратегий
компании в проектно ориентированном бизнесе.
Вторая и третья главы содержат изложение материала в соответствии с
PMBoK и посвящены вопросам, связанным с фазами жизненного цикла про-
екта (инициация; планирование; исполнение и завершение), и сопоставлению
процессов управления проектами (управление интеграцией, содержанием,
сроками, стоимостью, качеством, человеческими ресурсами, информацион-
ным взаимодействием, рисками и контрактами проекта) функциям Primavera.
В четвертой главе описывается состав информационной системы в виде
функциональных и обеспечивающих подсистем, приводится обзор про-
граммных средств управления проектами (MS Project 2003, Spider Project,
Welcom).
Пятая и шестая главы посвящены описанию архитектуры информацион-
ной системы управления проектами, построенной на базе Primavera и содер-
жат описание рекомендаций по ее применению в решении практических за-
дач управления проектами. Изложение ведется в соответствии с фазами жиз-
ненного цикла проекта.
Седьмая глава содержит практические рекомендации по проведению
анализа обобщенных данных проекта, отображению и печати временных гра-
фиков проекта.
Книга предназначена для специалистов и руководителей, занимающимся
внедрением методов проектного управления, отвечающих за сопровождение
информационной системы управления проектами в своей организации. Она
будет полезна преподавателям, аспирантам и студентам, изучающим дисцип-
лину «Управление проектами».

1
Трофимов В.В. и др. Управление проектами с Primavera: Учебное пособие. СПб.: СПбГУЭФ, 2006. – 216с.

6
 1. Методология управления проектами компании
1.1. Методы построения проектных моделей компании
Традиционно с позиции создания стоимости любое предприятие (ком-
панию) принято рассматривать как "продуктивную систему", производящую
полезные продукты и услуги. Но с другой стороны нужно признать, что пред-
приятие является "деструктивной системой", так как производственный про-
цесс связан с расходованием ресурсов, выбросами вредных веществ и созда-
нием специфических рисков.
Для построения модели предприятия с учетом его взаимодействия с
окружающей средой требуется рассмотрение его как подсистемы природы.
То есть, рассмотрение предприятия не только как экономического звена, реа-
лизующего процессы создания стоимости, но и как составной части природ-
ного кругооборота, воспроизводящей процессы нанесения экологического
ущерба.
При изучении предприятия как элемента экосистемы и построения его
системной и процессной моделей будем пользоваться методами системного
подхода — функциональным и структурным анализами.
Функциональный анализ рассматривает функционирование системы.
Причем под функцией системы, с одной стороны, понимается ее свойство в
динамике, приводящее к достижению цели (дескриптивное определение), с
другой стороны, — движение изображающей точки, соответствующей со-
стоянию системы, по некоторой траектории в пространстве состояний (кон-
структивное определение).
Структурный анализ предполагает выявление состава (элементов), и
определение структуры (связей между элементами). Причем, состав фор-
мальной структуры получается путем выделения дескрипторов в определе-
нии цели, а под самой формальной структурой понимается логическая струк-
тура цели системы. Отметим, что фиксированной цели соответствует одна
формальная структура, а одной формальной структуре соответствует множе-
ство материальных структур.
Следуя указанным методам, мы можем описать экосистему в целом,
выделить в ее составе предприятие, выявить его функцию и установить связи
с другими элементами экосистемы. Рассматривая само предприятие как сис-
тему, исходя из его функции (миссии), можем описать его структуру и связи
между элементами.
При анализе предприятия как экономической подсистемы главными
входными переменными выступают: капитал, труд и технологии, преобра-
зуемые в продукты и услуги (рис.1.1-1). При его рассмотрении как экологи-
ческой подсистемы на первое место выступают: природные ресурсы, выбро-
сы, отходы и риски. Иногда удобно предприятие рассматривать как инфор-
мационную систему, тогда основное внимание уделяют информационным
потокам, в которых информационные ресурсы преобразуются в информаци-
онные продукты и услуги.
7 8
Рис.1.1-1. Системная модель предприятия.
При рассмотрении экономико-производственного процесса на пред-
приятии выделяют фазы создания стоимости, находящиеся в ведении самого
предприятия, а при анализе экологических процессов включают в рассмотре-
ние как стадии, предшествующие основному производству (добыча сырья,
изготовление полуфабрикатов, получение заготовок, которые, как правило,
не реализуются на данном предприятии), так и стадии, следующие непосред-
ственно за ним (потребление, распределение, утилизация). То есть, системная
модель предприятия должна учитывать полный экологический жизненный
цикл продукта, включающий все связанные с ним стадии.
Предприятие вынуждено улучшать экологию производства под воздей-
ствием общественных требований, законодательных предписаний и рыноч-
ных отношений, которые являются управляющими. Таким образом, внешни-
ми системами, которые влияют на предприятие, являются — общество, госу-
дарство и рынок.
Первая система требует обеспечения безопасности деятельности пред-
приятия со стороны общественных групп и организаций (примером являются
организации занимающиеся охраной окружающей среды). Критерий оценки
деятельности предприятия — общественное мнение.
Вторая — требует выполнения законодательных актов и ведомствен-
ных норм в сфере охраны окружающей среды (в том числе предполагает ми-
нимизацию потребления природных ресурсов и нагрузки на природу). Кри-
терий оценки — экологическая эффективность.
Третья — оказывает давление на предприятие в форме растущих рас-
ходов на ликвидацию последствий выбросов, изменения требований к про-
дуктам с учетом их безопасности для окружающей среды, создания экологи-
ческих и инновационных фондов. Критерий оценки — экономическая эф-
фективность.
 К числу важнейших целей предприятия как экосистемы можно отне-
сти: уменьшение потребляемых природных ресурсов; ограничение выбросов;
сокращение отходов; ограничение риска; производство безвредных продук-
тов.
Наряду с анализом системы возможен и ее синтез с помощью струк-
турно-функционального метода, который решает две задачи — прямую и об-
ратную.
Прямая задача — это синтез структуры системы путем анализа задан-
ной функции (миссии) компании, которая решается с помощью:
1) анализа заданной цели путем ее декомпозиции (выявления состава
компании и необходимых условий для достижения заданной цели) на подце-
ли и построения дерева целей. Причем, дерево целей включает перечень под-
целей, их ранжирование и перечень ресурсов для их реализации;
2) синтеза структуры с учетом выделенных ресурсов, осуществляется,
обычно, снизу — вверх..
Обратная задача — зная состав и структуру системы, определить ее
цель (функцию).
Как было отмечено выше, первым шагом при построении систем-
ной модели предприятия является проведение границы, отделяющей
компанию от внешней среды. В результате определяются все входы и
выходы, которыми компания связана с окружающей средой (рис.1.1-1).
Второй шаг системного подхода требует выделения системы
управления, для чего в компании выделяют объект управления, субъект
управления и описывают процесс управления (рис.1.1-2).
Рис.1.1-2. Контуры управления компанией.
При рассмотрении такой схемы выделяют: возмущения ξ(t), по-
ступающие на объект управления и приводящие к отклонению выхода
объекта от заданных (нормативных, плановых) значений Y0; управляю-
щие воздействия U1(ξ(t)), компенсирующие эти отклонения
Δ(ξ(t))={Y(t)-Y0}; выход объекта Y(t); возмущающие воздействия внеш-
9 10
ней среды ζ(t), в которой функционирует объект управления; параметры
настройки контура управления q(t); параметры настройки объекта
управления G(t); управляющие воздействия U2(ζ(t)), компенсирующие
ζ(t) и формирующие {G(t),q(t),Y0} — этот контур называется контуром
стратегического управления компании.
Компания является стратегической хозяйственной системой, то
есть организацией, деятельность которой охватывает всю цепочку соз-
дания стоимости: инновации, операции, маркетинг, распределение, про-
дажи, сервис, и ее структура состоит из подсистем.
С ростом уровня нестабильности внешних условий предпринима-
тельской деятельности возрастает потребность компании в ориентации
на стратегическое управление. Стратегическое управление призвано
обеспечить выживание организации и достижение ее целей в долго-
срочной перспективе. При этом основное внимание руководства скон-
центрировано на внешнем окружении для быстрой и адекватной реак-
ции на изменения в нем.
Стратегическое управление компанией реализует следующие про-
цессы (рис.1.1-3): диагностика внешней и внутренней среды; проведе-
ние стратегического анализа; разработка концепции корпоративной
стратегии и программы действий; реализация стратегий; стратегический
контроллинг.
Рис.1.1-3. Процесс стратегического управления.

Для реализации процесса стратегического управления использу-
ются методы проектного управления, их место указано на рис.1.1-3 и
они будут рассмотрены ниже.
Процесс оперативного управления также может быть реализован
с помощью методов управления проектами, которые подробно описаны
в рекомендациях PMBoK американского института управления проек-
тами (PMI) и приведены на рис.1.1-4.
Рис.1.1-4. Процесс оперативного управления.
Весь процесс управления проектами может быть представлен в
виде фаз управления (инициация, планирование, исполнение, управле-
ние, закрытие) и процессов (управление: интеграцией, содержанием,
сроками, стоимостью, качеством, человеческими ресурсами, информа-
ционным взаимодействием, рисками, контрактами проекта).
1.2. Управление проектами и стратегии компании
1.2.1. Компания как объект стратегического управления
Стратегическое управление (strategic management) — деятель-
ность, связанная с постановкой целей и задач и с поддержанием ряда
взаимоотношений между компанией и окружением, которые позволяют
ей добиться своих целей, соответствуют ее внутренним возможностям и
позволяют оставаться восприимчивой к внешним требованиям.
11
С ростом уровня нестабильности условий предпринимательской
деятельности возрастает потребность компаний в ориентации на страте-
гическое управление. Способности к стратегическому менеджменту
предполагают наличие пяти элементов: 1) умение смоделировать ситуа-
цию; 2) умение выявить необходимость изменений; 3) умение разрабо-
тать стратегию изменений; 4) умение использовать в ходе изменений
надежные методы; 5) умение воплощать стратегию в жизнь.
Стратегия (strategy) — обобщающая модель действий, необходи-
мых для достижения поставленных целей путем координации и распре-
деления ресурсов компании. По существу стратегия есть набор правил
для принятия решений, которыми организация руководствуется в своей
деятельности. Процесс разработки стратегии включает: 1) определение
корпоративной миссии; 2) конкретизацию видения корпорации и поста-
новку целей; 3) формулировку и реализацию стратегии, направленной
на достижение целей.
В процессе стратегического управления выделяют следующие ос-
новные этапы (рис.1.1.-3 и 1.2-1): анализ внешней и внутренней среды;
формулирование миссии организации; определение ее целей; стратеги-
ческий анализ и разработка стратегий для достижения этих целей на ос-
нове концепции корпоративной стратегии; реализация стратегий с ис-
пользованием методов управления проектами; стратегический контрол-
линг (анализ) реализации стратегий (определение необходимости кор-
рекции миссии, целей, стратегий или мероприятий по их осуществле-
нию).
Этапы «Формулирование миссии», «Определение целей» и «Раз-
работка стратегий» часто объединяют в один этап «Стратегическое пла-
нирование», который является ключевым этапом стратегического
управления.
Способности Компании к стратегическому менеджменту и воз-
можность реализации сформулированных стратегий определяет нали-
чие у нее следующих пяти элементов:
1) умение моделировать ситуацию (требует наличия бизнес-
моделей Компании, внешней среды и процессов их взаимодействия);
2) умение выявлять необходимость изменений;
3) умение разработать стратегию изменений;
4) умение использовать в ходе изменений надежные методы
управления проектами;
5) умение воплощать стратегию в жизнь.
12
 помощью бизнес-процессов: исследования рынков, прогнозирование
рынков, реклама и дизайн, продвижение продуктов и услуг, анализ про-
даж;

Рис.1.2-2. Пути повышения рыночной стоимости предприятия.

2) стратегии «Лидерство по продуктам», «Доверительное отноше-

ние с клиентом», «Операционное совершенство», «Взаимоотношение с
обществом», которые реализуются с помощью бизнес-процессов: инно-
вационные процессы, управление отношениями с клиентами, операци-
онные процессы, процессы регулирования деятельности.

Рис.1.2-1. Место управления проектами среди этапов

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

Все пять элементов реализуются в интегрированной системе стра-

тегического управления в виде следующих функциональных подсистем,
обеспечивающих поддержание деятельности и развитие Компании: про-
гнозирования; планирования; экономического анализа; организации;
оперативного регулирования; учета; контроля.
Одной из главных задач компании является увеличение прибыли
предприятия, которое может происходить путем роста доходов за счет
развития новых источников доходов, и/или увеличения потребитель-
ской ценности для клиента, и/или снижения затрат за счет повышение
эффективности использования, и/или улучшения структуры издержек2
(рис.1.2-2).
В свою очередь развитие новых источников доходов (рис.1.2-3)
может опираться на:
1) стратегии «Выхода на новые рынки», «Расширение видов про-
дуктов и услуг», «Увеличение числа клиентов», которые реализуются с

2
Товб А.С., Ципес Г.Л. Управление проектами: стандарты, методы, опыт. — 2-е
Рис.1.2-3. Стратегии роста доходов.
изд., стер. — М.: ЗАО «Олимп-Бизнес», 2005. — 240с.
13 14
 Снижение затрат (рис.1.2-4) может опираться на:
1) стратегии «Приобретение/списание основных средств», «Долго-
срочные финансовые вложения», «Дебиторская задолженность», «Не-
материальные активы», реализуемые с помощью бизнес-процессов:
управление основными средствами, управление финансами, управление
персоналом, управление интеллектуальным капиталом, управление
брэндом;
Рис.1.2-4. Стратегии снижения затрат.
2) стратегии «Управление системой поставок», «Оптимизация ло-
гистических схем», «Эффективность производства», «Эффективность
системы сбыта», реализуемые с помощью бизнес-процессов: закупка
оборудования и пр., транспортное обеспечение, хранение на складах,
производство, продажи, оказание услуг.
1.2.2. Формирование бизнес-модели компании
Опираясь на базовые стратегии, строится бизнес-модель Компа-
нии (рис.1.2-5), которая представляет собой совокупность информаци-
онных моделей, обеспечивающих необходимую полноту и точность
описания бизнеса компании. К информационным моделям относятся:
15
модель целеполагания; организационная модель; технологическая мо-
дель; процессная модель; проектная модель; модель структуры данных3.
Бизнес-модель компании является не только основой управления
организацией. Высокая прозрачность бизнеса, простота и доступность
системного описания позволяет разработать исходное техническое за-
дание на настройку системы управления ресурсами (например, системы
ERP) и осуществить разработку новых требований по совершенствова-
нию (подстройке) системы управления ресурсами. Это позволяет обес-
печить необходимые ресурсы, требуемое качество, в необходимом ко-
личестве, в нужном месте, в заданное время, за приемлемую цену, и
снизить производственные издержки, обеспечив, таким образом, повы-
шение конкурентоспособности компании.
Рис.1.2-5. Полная бизнес-модель компании.
3
http://big.spb.ru/publications/bisspb/bm_complex_upr.shtm
16
 В этом случае в бизнес-модель вносятся упреждающие корректи-
ровки не под действием уже свершившихся изменений на рынке, а на
основании стратегического прогноза таких изменений. Это обеспечива-
ет чрезвычайно высокую конкурентоспособность саморазвивающейся
компании.
Менеджеры получают на основе бизнес-модели необходимые рас-
порядительные документы (должностные инструкции, положения, дру-
гие управленческие регламенты, оперативные и стратегические отчеты
о наличии и движении ресурсов в компании и т.д.).
На основе построенных бизнес-моделей формируются все необхо-
димые регламенты компании. Например: Регламент управления проек-
тами; Регламент планирования и ведения проектов в ИСУП; Регламент
управления рисками проектов; Регламент обеспечения качества проек-
тов; Регламент внутрифирменного планирования и отчетности.
1.3. Модель организационной зрелости управления проек-
тами
Концепция зрелости ориентирована на достижение успеха в биз-
несе за счет повышения конкурентоспособности компании путем оце-
нивания зрелости своих бизнес-процессов. Зрелость управления проек-
тами имеет определенные особенности, так как ее рассматривают как
инструмент развития фирмы через постоянное совершенствование ме-
тодологии управления проектами, более глубокое ее интегрирование в
общую систему управления компанией и достижение повторяемости
успехов в выполнении проектов.
Термин «Организационная зрелость по управлению проектами»
описывает способность организации отбирать проекты и управлять ими
таким образом, чтобы это максимально эффективно поддерживало дос-
тижение стратегических целей компании.
Модель зрелости управления проектами позволяет увидеть силь-
ные и слабые стороны, понять, где находится компания и спланировать
траекторию движения по улучшению системы управления проектами.
Модель организационной зрелости управления проектами (Organ-
izational Project Management Maturity Model — OPM3), которая разрабо-
тана Институтом управления проектами (Project Management Institute —
PMI) призвана стать для организаций тем, чем стал Свод знаний PMBoK
(Project Management Body of Knowledge) для проектов. OPM3 позволяет
фирмам понять концепцию зрелости управления проектами, оценить
свой уровень зрелости и выбрать оптимальный путь ее повышения.
OPM3 является своего рода ключом к организационной зрелости
управления проектами и содержит три взаимосвязанных элемента:
17
• элемент ЗНАНИЕ (KNOWLEDGE) представляет собой сотни луч-
ших практик по управлению проектами, характеризующих те или
иные уровни организационной зрелости УП;
• элемент ОЦЕНКА (ASSESSMENT) является инструментом, помо-
гающим организациям оценить текущую зрелость по УП и опре-
делить области улучшения;
• элемент УЛУЧШЕНИЕ (IMPROVEMENT), который помогает
компаниям построить схему развития управления проектами та-
ким образом, чтобы обеспечить максимально эффективное дости-
жение своих стратегических целей.
Точно также как PMBoK является настольной книгой профессио-
налов УП, теперь ни одна организация не может позволить себе разви-
ваться по стезе управления проектами без OPM3.
Крайне важным является то, что для организаций, желающих раз-
вивать управление проектами, OPM3 предоставляет руководство, кото-
рое помогает грамотно планировать шаги по развитию, определять при-
оритеты и экономя тем самым ресурсы компании. Итак, в результате:
• стандарт состоит из свода знаний (в привычном формате книги) и
инструментария модели, организованного в виде базы данных на
CD (оценочный опросник и директория лучших практик и способ-
ностей (best practices и capabilities));
• стандарт использует для структурирования лучших практик и спо-
собностей пять процессов управления проектами в соответствии с
PMBOK Guide;
• инструментарий оценки и рекомендаций по совершенствованию
основан на применении структурированного набора способностей
— конкретных компетенций (умений), которые должны существо-
вать в компании для того, чтобы она могла успешно осуществлять
процессы управления проектами, и лучших практик — оптималь-
ных, с точки зрения конкретной области применения, способов
достижения определенной цели или показателя. Все элементы
структурированы, а многие непосредственно взаимосвязаны меж-
ду собой.
• для описания шагов по совершенствованию управления проектами
в организации используется концепция последовательного улуч-
шения процессов, лежащая в основе TQM (стандартизация, изме-
рение, контроль, совершенствование);
• для описания различных уровней зрелости организационного
управления проектами используются понятия программы и порт-
феля;
18
 • большую часть стандарта представляет собой пошаговое описа-
ние, как применять модель, включая инструментарий оценки (оп-
росник) и совершенствования (директории Лучших Практик и
Способностей).
Основное назначение OPM3 — быть стандартом для корпоратив-
ного управления проектами и организационной зрелости по управлению
проектами.
Основная отличительная черта OPM3 — это наличие уникальной
базы данных, поставляющейся на CD-ROM, которая содержит сотни
лучших практик, описание тысяч Ключевых Факторов Успеха, Резуль-
татов и другой информации, характеризующей развитие зрелости
управления проектами в организации.
Схематично стандарт ОРМ3 можно представить в виде графика,
изображенного на рис.1.3-1.
Рис.1.3-1. Модель зрелого управления проектами.
Уровень 1 — терминология. Компания осознает важность управ-
ления проектами и необходимость усвоения знаний и сопутствующего
им языка в области управления проектами.
Уровень 2 — общие процессы. Компания разрабатывает общие
процессы управления проектами для повторения результатов успешных
19
проектов и применяет принципы управления проектами к другим мето-
дологиями компании.
Уровень -3 — единая методология. При объединении всех мето-
дологий в единую получается синергетический эффект, облегчающий
управление всеми процессами компании.
Уровень 4 — бенчмаркинг. Для сохранения и развития конкурент-
ного преимущества компании перед конкурентами компания улучшает
свои процессы путем непрерывного проведения бенчмаркинга.
Уровень 5 — непрерывное улучшение. Развитие единой методоло-
гии компании, используя результаты бенчмаркинга.
OPM3 спроектирована таким образом, чтобы быть легкой в пони-
мании и использовании, масштабируемой и гибкой. Основываясь на ба-
зе OPM3 как стандарта управления проектами, организация может ус-
пешно перейти к такому состоянию, когда проекты будут достигать по-
ставленных целей в рамках бюджета, сроков и, что более важно, пре-
следуя корпоративные стратегические цели.
Стандарт, несомненно, является ценной с практической точки зре-
ния разработкой. В настоящее время существуют модели зрелости, бо-
лее точные по некоторым отдельным аспектам (например, лучше учи-
тывающие особенности корпоративной культуры, или с более прорабо-
танными оценочными опросниками), но благодаря относительной про-
стоте использования и рыночному потенциалу PMI, OPM3 может пре-
тендовать на роль действительно глобального стандарта. В нашей стра-
не перспективы его использования видятся, в первую очередь, в области
"внутреннего" бенчмаркинга, а также как основы для консалтинговых
продуктов и услуг.
1.4. Информационная система управления проектами как
инструмент реализации стратегий компании
Интегрированная система управления развитием (ИСУР) компа-
нии осуществляет управление в целях повышения эффективности ее
деятельности и включает (рис.1.4-1): систему стратегического управле-
ния (ССУ), систему производственного управления (СПУ) и систему
стратегического развития (ССР).
ССР обеспечивает реализацию следующих бизнес-процессов
(рис.1.4-1): инициирования, планирования и контроля проектов; деталь-
ного планирования; исполнения и контроля проектов; завершения про-
ектов; внедрения и контроля результатов проектов.
Например, основу организационной структуры ССР могут состав-
лять: высший коллегиальный (законодательный) орган по стратегиче-
скому развитию компании — Совет по развитию; Департамент развития
20
и Центр управления проектами должны отвечать за планирование и кон-
троль реализации принимаемых решений по развитию Компании, а
Группа управляющих проектами отвечать за реализацию инициирован-
ных проектов развития.
Рис.1.4-1. Схема бизнес-процессов Интегрированной системы
управления развитием компании.
Укрупненная целевая организационная структура управления раз-
витием такой компании приведена на рис.1.4-2.
Рис.1.4-2. Место УП в организационной
структуре компании.
Информационная система управления проектом (ИСУП) — аппа-
ратно-программный комплекс, предназначенный для накопления, обра-
21
ботки, хранения, визуализации и анализа информации проектов. Ото-
ждествление ИСУП с управлением проектом — распространенная
ошибка. Программный комплекс ИСУП — всего лишь инструмент
управляющего проектом и команды управления проектом. И, что очень
важно, это эффективный инструмент руководства организации, обеспе-
чивающий контроль планирования и ведения проектов и позволяющий
минимизировать управленческие ошибки при реализации проектов.
Рынок современного программного обеспечения по управлению
проектами представлен широким спектром продуктов, различающихся
назначением и уровнем заложенных в них возможностей. Они пред-
ставлены как несложными настольными приложениями, не поддержи-
вающими сетевой работы, так и современными программными средст-
вами, построенными на web-технологиях, поддерживающими много-
пользовательскую работу с данными проекта, и при помощи которых
возможно построение целостной корпоративной системы управления
проектами.
Не так давно программы управления проектами решали лишь за-
дачу календарного планирования и имели ограниченные возможности
ресурсного и бюджетного планирования. Ситуация быстро меняется, и
сейчас производители программного обеспечения предлагают широкий
спектр программ, как универсальных, так и ориентированных на проек-
ты определенного типа и обеспечивающих реальные потребности
управляющих проектами.
Несмотря на то, что всякий проект по определению уникален, тре-
бования, предъявляемые управляющими проектами к программным
средствам управления проектами, достаточно легко поддаются обобще-
нию. Начнем, отвлекаясь от корпоративных потребностей, с потребно-
стей планирования и ведения «одиночного» проекта. Программное
средство управления таким проектом должно:
• Обеспечивать автоматизированное построение календарного пла-
на любой сложности. То есть в зависимости от введенного переч-
ня работ, определенных длительностей и установленных зависи-
мостей между работами должен автоматически формироваться
временной график (расписание) проекта с учетом разбиения на со-
ответствующие этапы и подэтапы.
• Автоматически выделять работы критического пути. К работам
критического пути относятся те работы, срыв сроков выполнения
любой из которых приведет к срыву срока окончания проекта.
• Предусматривать отображение плана проекта, как в графическом
виде, так и в табличной форме.
22
 • Обеспечивать контроль и регистрацию движения денежных Всем этим требованиям в полной мере удовлетворяет линейка
средств. программных продуктов фирмы Primavera — бессменного лидера на
• Предусматривать возможность разработки и сохранения альтерна- рынке программных средств управления сложными проектами.
тивных планов проекта (это мощное средство минимизации рис- Модуль «Управление проектом» является ключевым инструмен-
ков, связанных с ошибками планирования). том реализации стратегии развития компании и составляет основу сис-
• Обеспечивать закрепление за работами проекта ресурсов различ- темы стратегического развития, т.к. обеспечивает деятельность по пла-
ного вида и контроль уровня их загрузки. нированию, руководству, координации трудовых, финансовых и мате-
• Обеспечивать настройку интерфейса программы, формирования риальных ресурсов на протяжении всего жизненного цикла проектов
необходимых форм отчетов и их автоматическую генерацию. развития Компании. С его помощью достигаются определенные руко-
• Обеспечивать ведение электронного дела проекта: присоединение водством Компании цели, реализуются заданные состав и объемы ра-
к работам и этапам проекта гиперссылок на соответствующие до- бот, выполняются ограничения, накладываемые на их стоимость, время
кументы, сопровождающие процесс исполнения проекта. и качество.
• Обеспечивать защиту информации проекта от несанкционирован- Одной из важных моделей, является проектная модель предпри-
ного доступа. ятия, которая используется в системе стратегического развития (ССР),
реализуется с помощью методов управления проектами и тесно связана
Программное обеспечение, выбираемое в качестве основы корпо- с функциональными подсистемами интегрированной системы предпри-
ративной ИСУП, дополнительно должно обеспечивать: ятия. Наиболее тесное взаимодействие функций управления проектами
с подсистемами интегрированной информационной системы предпри-
• Управление портфелями проектов: анализ влияния инициации но-
ятия приведено на рис.1.4-3.
вых проектов на портфель проектов в целом.
• Разрешение ресурсных конфликтов, определение «общих» ресур-
сов, которые могут быть использованы во всех подразделениях
компании.
• Управление внутрипроектными зависимостями и зависимостями
между всеми проектами организации.
• Поддержку географически распределенных сложных проектов с
географически распределенными командами.
• Сохранение и анализ уже выполненных проектов для совершенст-
вования бизнес-процессов организации.
• Идентификацию и категоризация рисков и проблем, которые мо-
гут возникнуть при реализации будущих проектов.
• Интеграция информации по проектам с внешними информацион-
ными системами и приложениями организации.
• Многократное использование планов и шаблонов успешно реали-
зованных проектов.
• Сохранение больших объемов проектных данных и информации
по всей компании.
• Возможность распределенного выполнения задач, характерных Рис.1.4-3. Взаимодействие подсистем интегрированной информационной
для управления проектами: расчет расписания, выравнивание ре- системы предприятия и функций управления проектами.
сурсов, отчетность по отдельным проектам, компании в целом и
портфелям проектов. Из этого рисунка видно, что наиболее важными функциями управ-
ления проектами являются функции управления командой проекта и
23 24
контрактами, а наиболее важными среди подсистем является подсисте-
ма управления документами.
1.5. Проектно-ориентированный бизнес
Проектно-ориентированный бизнес — это бизнес, результаты ко-
торого доставляются потребителю в виде реализованных проектов и
программ, целью которых являются создание продуктов и представле-
ние разнообразных услуг. Здесь бизнес — это производственная систе-
ма, на входе которой заказы, контракты, соглашения и договоры, каж-
дый из них реализуется как программа или проект, и на выходе предос-
тавляются заказчику вновь созданные продукты и услуги (рис.1.5-1).
Рис.1.5-1.Системная модель управления проектами компании
Компания, провозгласившая ориентацию на проектное управле-
ние, должна создать систему управления проектами, основанную на
реализации системной модели управления проектами, которая содер-
жит: объект управления (программы, портфели, проекты и контракты),
на разных фазах жизненного цикла (концепция, разработка, реализация
и завершение); субъект управления, включающий ключевых участников
УП (инвестор, заказчик, генеральный контрактор, генеральный подряд-
чик, исполнители) и команду УП (менеджер проекта и функциональные
менеджеры); процесс управления, описывающий в соответствии с
PMBoK функции УП (управление: интеграцией, содержанием, сроками,
стоимостью, качеством, человеческими ресурсами, информационным
25
взаимодействием, рисками и контрактами проекта), временные горизон-
ты управления (стратегический. тактический и оперативный), стадии
УП (инициация, планирование, исполнение, управление, закрытие).
На базе системной модели управления проектами компании фор-
мируются различные подсистемы, в том числе: организационная и ин-
формационная структуры; подсистема документационного обеспечения;
управление рисками проекта.
1.5.1. Организационная структура управления проектами
Организационная структура управления проектами — комплекс
управленческих и функциональных подразделений компании, должно-
стных лиц и сотрудников, объединенных системой информационных и
управленческих связей на основе корпоративной информационной сис-
темы (КИС) и информационной системы управления проектами
(ИСУП) компании, реализующий контроль, анализ и управление проек-
том на всех фазах жизненного цикла.
Связи между должностями и структурными подразделениями мо-
гут быть либо вертикальные (административно-функциональные), по
которым протекают административные процессы принятия решений,
либо горизонтальные (технологические), по которым протекают про-
цессы выполнения работ.
Проектирование, анализ и создание организационной структуры
управления проектами являются ответственной, сложной, междисцип-
линарной, слабо структурируемой и формализуемой деятельностью, ко-
торая опирается на следующие общие принципы:
1. соответствие организационной структуры системе взаимоотношений
участников проекта;
2. соответствие организационной структуры содержанию проекта;
3. соответствие организационной структуры требованиям внешнего ок-
ружения.
В соответствии с первым принципом используются следующие
организационные структуры и системы взаимоотношений с участника-
ми проекта:
• «выделенная» (разовая или «адхократическая») организаци-
онная структура управления проектами применяется тогда,
когда основные механизмы управления и непосредственные
источники основных ресурсов проекта находятся в рамках
одной организации и после завершения проекта такая струк-
тура ликвидируется;
• «управление по проектам» — когда «выделенная» организа-
ционная структура управления проектом превращается во
внутреннюю, постоянно действующую структуру;
26
 • «всеобщее управление проектами» — когда организационная
структура проекта и «материнской» организации составляют
единое целое и управляются общей системой управления;
• «двойственная» (dual) организационная структура — когда в
проекте участвуют две равнозначные с точки управления
проектом, организации;
• «сложные» организационные структуры — когда в проекте
участвуют более двух различных организаций, имеющих
различные значимые функции в этом проекте. Возможны
следующие три базовых варианта — управление проектом
реализуют: заказчик, генеральный подрядчик, специализиро-
ванная управляющая фирма.
Второй принцип требует соответствия организационной структу-
ры содержанию проекта и предъявляет требования по оптимальной ор-
ганизационной структуре проекта с точки зрения внутреннего организа-
ционного устройства проекта, т.е. с точки зрения разделения труда, за-
кладываемого в организационной структуре. При реализации этого
принципа используются следующие организационные структуры:
функциональная; матричная; проектно-целевая; дивизиональная и сме-
шанная.
Третий принцип устанавливает соответствие между организаци-
онной структурой проекта и подвижностью внешнего окружения. Чем
оно подвижнее и динамичнее, тем более гибкой и адаптивной (органи-
стической) должна быть организационная структура проекта. Чем ста-
бильнее и определеннее внешняя среда, тем эффективнее в применении
«жесткие», механистические, бюрократические организации.
Организационным, методологическим и контролирующим цен-
мерческой деятельности по предоставлению услуг сторонним организа-
тром корпоративной структуры управления проектами является центр
циям по постановке систем проектного управления и управлению про-
(офис) управления проектами (ЦУП) компании.
ектами.
Задачи, решаемые ЦУП, многообразны и зависят от специфики
организации и особенностей реализуемых ею проектов. В организациях,
должны выполняться следующие функции:
ведущих небольшое число проектов, на ЦУП часто возлагаются обязан-
ности по непосредственному управлению проектами или оказанию тех-
нической помощи управляющим проектами по планированию и веде-
нию проектов в ИСУП. В организациях, ведущих значительное число
проектов или многопроектных программ, ЦУП формируется как мето-
дологический и контрольный орган. Задачами такого ЦУП являются:
• формирование и развитие организационной системы управления
проектами компании;
• разработка и внедрение системы документационного обеспечения
управления проектами компании;
27
• внедрение и обеспечение эффективной эксплуатации и развития
информационной системы управления проектами компании
(ИСУП);
• контроль качества планирования и ведения проектов компании в
ИСУП;
• анализ эффективности и разработка предложений по совершенст-
вованию системы проектного управления компании;
• разработка программ обучения, учебно-методических материалов
и организация обучения и консультирования управляющих проек-
тами и специалистов команд управления проектами;
• ведение архива проектов в ИСУП;
• формирование базы данных типовых моделей проектов и типовых
этапов проектов для использования при запуске очередного про-
екта компании;
• подготовка решений руководства по управлению ресурсами ком-
пании с целью безусловного исполнения проектов в заданные сро-
ки с требуемым качеством;
• формирование и обеспечение эффективного функционирования
распределенной системы управления рисками компании;
• формирование и ведение базы рисков проектов и базы рисков
компании;
• формирование методологической базы оценки и минимизации
рисков;
• организация и проведение экспертных оценок рисков проектов и
рисков компании
Как отдельная задача может рассматриваться организация ком-
Для решения указанных задач центром управления проектами
• методологическая — разработка и внедрение документов системы
документационного управления проектами, создание типовых мо-
делей проектов и выдача их в команды управления проектами на
фазах инициации и планирования, выявление и формирование ти-
повых фрагментов проектов для последующего использования,
разработка учебно-методических материалов, программ подготов-
ки и организация обучения сотрудников планированию и ведению
проектов в ИСУП, методологическое обеспечение оценки и мини-
мизации рисков проектов и рисков компании;
28
 • аналитическая — анализ качества управления ведущимися проек- • обеспечение обучения управляющих проектами планированию и
тами, анализ эффективности управления завершенными проекта- ведению проектов в информационной системе управления проек-
ми, анализ рисков проектов и рисков компании, подготовка реше- тами компании.
ний управляющих проектами или руководства компании по Вариант структуры системы документационного обеспечения
управлению ресурсами проектов и минимизации рисков проектов; управления проектами, реализованный в одной из энергетических ком-
• архивная — хранение информации, формализация накопленных паний, приведен на рисунке 1.5-2.
дел проектов, ведение базы данных типовых проектов и типовых
этапов проектов, ведение базы данных рисков проектов и рисков
компании;
• инфраструктурная — участие в проектах по созданию и развитию
ИСУП, менеджмент лицензий и прав на доступ к ИСУП, контроль
технологического состояния ИСУП, поддержка функционирова-
ния распределенной системы управления рисками компании;
• контрольная — мониторинг планов и хода реализации проектов и
загруженности ресурсов, обработка и доведение до руководства
компании и управляющих проектами информации о выявляемых
недостатках.
Центр управления проектами является владельцем нескольких,
вспомогательных по отношению к основной деятельности компании,
бизнес-процессов. К ним, прежде всего, относятся:
• контроль правильности планирования проекта в ИСУП;
• контроль ведения проекта в ИСУП.
• бизнес-процесс формирования базы данных типовых моделей про-
ектов и типовых этапов проектов для использования при запуске
очередного проекта.
1.5.2. Документационное обеспечение управления проектами
Система документационного обеспечения управления проектами
— комплекс нормативных, организационно-распорядительных и учеб-
но-методических документов, обеспечивающих эффективное функцио-
нирование организационной системы управления проектами и взаимо-
действие ее компонентов с информационной системой управления про-
ектами компании. Задачами этой системы являются:
• формирование идеологии и методологии управления проектами в
компании;
• регламентация бизнес процессов, обеспечивающих внедрение
Рис. 1.5-2. Вариант структуры системы документационного обеспечения
проектного управления;
управления проектами
• обеспечение практической реализации матричной схемы управле-
ния при планировании и исполнении проектов компании; Основным документом приведенной на рисунке 1.5-2 системы яв-
• разграничение прав, обязанностей и ответственности исполните- ляется «Регламент управления проектами», разработанный с учетом ре-
лей проекта; комендаций стандарта управления проектами ANSI PMI PMBOK
29 30

2. Процессы управления проектами компании
Американский национальный стандарт для управления проектами
Project Management Body of Knowledge (PMBOK) - Свод знаний по
управлению проектами - это пример одного из самых популярных стан-
дартов в области управления проектами. Он представляет собой сово-
купность профессиональных знаний по управлению проектами и со-
ставлен на основе опыта коллектива авторов по управлению крупными
национальными и международными проектами. Свод знаний опирается
на мнение практиков и теоретиков в этой области. Полный свод знаний
по управлению проектами (PMBOK) включает как широко используе-
мые и зарекомендовавшие себя традиционные практики, так и недавно
появившиеся инновационные практики.4 Печатный вариант PMBOK
продается многомиллионными тиражами. Он завоевал уважение и при-
знание руководителей проектов по всему миру, в том числе и в России,
что подтверждается постоянным ростом желающих сертифицироваться
на PMP (Project Management Professional). Часто процессы, описанные в
стандарте, используются для управления отдельно взятыми проектами
по инициативе руководителей, использующих «западный» подход к
управлению. Однако следует отметить, что авторы также часто встре-
чают и ситуацию, когда процессы управления проектами описанные в
PMBOK, уже включены в корпоративные стандарты управления проек-
тами российских компаний и используются в масштабах целой органи-
зации.
Программное обеспечение Primavera
Primavera - это семейство современных профессиональных про-
дуктов, которое осуществляет полную информационную поддержку
процессов управления проектами, программами и портфелями проектов.
Разработчиком программного обеспечения выступает американская
компания Primavera Systems, Inc. Она на протяжении более чем двадца-
ти лет занимается разработкой специализированных решений по управ-
лению проектами. По всему миру насчитывается около ста тысяч ком-
паний-пользователей Primavera. В России их насчитывается более трех
тысяч, и каждый год их количество растет. Primavera – единственное в
мире программное обеспечение, которое на протяжении пяти лет нахо-
дится в квадранте лидеров в отчетах Gartner Group, отражающих теку-
щее положение на рынке специализированных решений по управлению
проектами и портфелями проектов, что говорит о постоянном развитии
4
Руководство к Своду знаний по управлению проектами. Третье издание. Американский национальный
стандарт ANSI/PMI 99-001-2004, стр.4
33
и совершенствовании ПО Primavera. В основу функциональных воз-
можностей Primavera входит модель, описанная в PMBOK, и опыт
управления как небольшими, отдельно взятыми проектами, так и авто-
матизации проектной деятельности крупнейших транснациональных
компаний по всему миру.
Ниже представлено краткое описание групп процессов и областей
знаний, приведенных в PMBOK. Те, кому уже удалось познакомиться со
стандартом, могут перейти непосредственно к разделу «Карта соответ-
ствия Primavera и процессов PMBOK».
Для описания модели стандарта нужно в первую очередь дать оп-
ределение проекту и управлению проектами:
• Проект – это временное предприятие, предназначенное для
создания уникальных продуктов, услуг или результатов.
• Управление проектами – это приложение знаний, навыков, ин-
струментов и методов к работам проекта для удовлетворения
требований, предъявляемых к проекту. Иначе говоря, это набор
процессов инициации, планирования, исполнения, мониторинга
и контроля, закрытия проекта для реализации его целей.
В PMBOK описаны 44 процесса управления проектами, которые
объединены по областям знаний и группам процессов, что позволяет
рассмотреть каждый процесс в двух плоскостях. Характеристиками ка-
ждого процесса являются:
• входы (примерами могут быть - документы проекта, факторы
внешней среды предприятия, активы организационного про-
цесса, а также необходимые выходы предыдущего процесса и
т.д.);
• выходы (продукт, результат или услуга; примерами могут быть
- документы проекта, запрошенные изменения, рекомендован-
ные корректирующие и предупреждающие действия и т.д.);
• рекомендованные инструменты и методы, которые применяют-
ся для эффективного выполнения процесса (например, вырав-
нивание ресурсов, метод критического пути и т.д.).
Важной особенностью PMBOK является группировка процессов
по областям знаний, которая позволяет оценить требования к квалифи-
кации руководителя и команды проекта. Нумерация процессов дается в
соответствии с PMBOK:
04. Управление интеграцией проекта (Project Integration Management)
– предназначено для выявления, определения, объединения, унифика-
ции и координации различных процессов управления проектами.
05. Управление содержанием проекта (Project Scope Management). По
определению, содержание проекта (project scope) – это работы, которые
34
необходимо выполнить, чтобы получить продукт, услугу или результат
с указанными характеристиками и функциями. Соответственно Управ-
ление содержанием проекта – это набор процессов, обеспечивающих
включение в профект именно тех работ, которые необходимы для ус-
пешного выполнения проекта.
06. Управление сроками проекта (Project Time Management) – область
знаний, которая отвечает за первоначальную разработку графика реали-
зации проекта с учетом набора работ, технологии и взаимосвязи работ,
оценки требуемых ресурсов, и исходя из этого, оценки длительностей
работ. Перечисленные выше процессы относятся к типу «планирова-
ние». Кроме них в Управление сроками проекта включается еще один
процесс «контроля», который в русском переводе звучит как «управле-
ние расписанием». Он предназначен контролировать реализацию проек-
та, а именно: определять текущее состояние расписания проекта; влиять
на факторы, создающие изменения в расписании; выявлять факты изме-
нения расписания проекта и управлять изменениями по мере их возник-
новения.
07. Управление стоимостью проекта (Project Cost Management) – пла-
нирование и контроль стоимости работ для завершения проекта в рам-
ках утвержденного бюджета. В процессах области управления стоимо-
стью определяется стоимость отдельных работ, исходя из требуемых
ресурсов и выплат, производится суммирование исходных оценок стои-
мости всех работ до уровня проекта и формируется базовый бюджет
проекта. В ходе выполнения происходит управление изменениями базо-
вого (целевого) плана по стоимости на основании фактических данных.
08. Управление качеством проекта (Project Quality Management). Для
понимания содержания этой области знаний нужно дать определение
качества как такового. По определению, которое дано в PMBOK: «Каче-
ство – это степень, в какой совокупность внутренних характеристик че-
го-либо соответствует требованиям». Соответственно, управление каче-
ством проекта – это комплекс процессов, которые направлены на удов-
летворение требований, ради которых проект был предпринят, при этом
требования – это четко сформулированные потребности, пожелания и
ожидания участников проекта.
09. Управление человеческими ресурсами (Project Human Resource Man-
agement) – это процессы организации и управления командой проекта.
Она состоит из людей, каждому из которых назначена определенная
роль и ответственность за выполнение проекта.
10. Управление коммуникациями проекта (Project Communication Man-
agement) – это область знаний, включающая в себя процессы, необходи-
мые для своевременного создания, сбора, распространения, хранения,
получения и, в конечном итоге, использования информации проекта.
35
Процессы управления коммуникациями проекта предусматривают соз-
дание необходимых связей между людьми и информацией, которые
требуются для успешного осуществления коммуникаций.
11. Управление рисками проекта (Project Risk Management). Процессы
по управлению рисками нужны для того, чтобы повышать вероятность
возникновения и воздействия благоприятных событий и снижение веро-
ятности возникновения и воздействия неблагоприятных для проекта со-
бытий. Соответственно, риск – это неопределенное событие или усло-
вие, которое в случае возникновения имеет позитивное или негативное
воздействие, по меньшей мере, на одну из целей проекта по срокам,
стоимости, содержанию или качеству.
12. Управление поставками проекта (Project Procurement Management)
– процессы покупки или приобретения тех необходимых для реализации
проекта продуктов, услуг или результатов, которые производятся вне
исполняющей проект организации.
Девять областей знаний PMBOK рисуют комплексную картину
тех типов знаний, которые задействованы в управлении проектами, и от
эффективного применения которых зависит успех проекта.
Для окончательного представления модели стандарта следует
упомянуть о группах процессов. Они необходимы для понимания логи-
ки следования процессов управления друг за другом. Управление про-
ектом можно описать как последовательное осуществление процессов:
инициации, планирования, исполнения, мониторинга и контроля, за-
вершения. Каждый из перечисленных укрупненных процессов и образу-
ет группу. Соответственно группы процессов объединяют в себе про-
цессы одного типа5.
5
Однако не следует путать группы процессов с фазами жизненного цикла проекта, которые зависят от спе-
цифики продукта проекта, т.е. содержание фаз связано с технологией создания продукта проекта. Например,
жизненный цикл проекта разработки программного обеспечения, состоит из четко определенных фаз: сбор
требований, проектирование, кодирование, тестирование и эксплуатация.
36

3. Карта соответствия функций Primavera и процессов
PMBOK
Многие руководители проектов, прочитавшие PMBOK, и тем бо-
лее те из них, которые взяли его за основу для своей деятельности, на-
верное, задавались вопросом: «Интересно, а есть ли такие инструменты,
которые автоматизировали бы все…, ну или хотя бы большинство опи-
санных в PMBOK процессов?» Или лучше: «А существует ли один та-
кой инструмент? Инструмент, который содержит всю необходимую
функциональность, способную объединить и команду проекта, и испол-
нителей, и руководство компании – всех участников в одной информа-
ционной среде взаимодействия?». Авторы статьи ни раз слышали эти
вопросы от разных руководителей проектов. Ответом стало создание
карты соответствия процессов, показывающая взаимосвязь процессов
PMBOK и функциональных возможностей программного обеспечения
Primavera.
3.1. Группа процессов Инициации
04.0 Управление интеграцией проекта (Project Integration Man-
agement)
04.1. Разработка устава проекта
Это процесс принятия решения о запуске проекта. Разработку ус-
тава проекта можно рассматривать как отдельный проект. Многие орга-
низации для этого используют унифицированный набор этапов, которые
должны быть выполнены, прежде чем происходит утверждение на за-
пуск нового проекта. Стандартный набор работ создается из шаблона
инициации корпоративной базы методологий. Отдельный контроль над
выполнением таких работ позволит обеспечить высокое качество при-
нимаемого решения и равные условия для всех предлагаемых инициа-
тив.
В ходе разработки устава проекта Primavera поддерживает сле-
дующие процессы: согласование устава проекта с ответственными за
его утверждение в соответствии с принятой процедурой; сохранение
версий документа; проведение обсуждений в рамках отдельных рабочих
групп по разработке разделов документа; хранение и доступ к уставу
проекта на портале системы. Если процесс инициации в компании рас-
сматривается как отдельный проект, то для его управления используют-
ся большинство из представленных в PMBOK процессов.
На основании разработанного устава проекта в организации запус-
кается процесс инициации проекта. Шаблоны инициации содержат рег-
37
ламентированные в организации этапы согласования нового проекта и
перечень ответственных за рецензирование каждого из этапов. Процесс
завершается автоматическим созданием проекта на основе введенных
данных. Это позволяет перейти к следующему процессу - разработке
предварительного содержания проекта.
04.2. Разработка предварительного содержания проекта
После создания проекта на предыдущем этапе, сотрудники,
имеющие доступ к созданному проекту, могут приступить к описанию
предварительного содержания проекта. Для автоматизации этого про-
цесса целесообразно использовать корпоративную базу типовых фраг-
ментов проектов. Механизм определения сложности проекта позволяет
изменять характеристики добавляемых работ в зависимости от органи-
зационных, внешних или контрактных условий.
3.2. Группа процессов Планирования
04.0 Управление интеграцией проекта (Project Integration
Management)
Согласование, утверждение и хранение разрабатываемых доку-
ментов для плана управления проектом производится на портале систе-
мы. При внесении изменений используются процессы запросов измене-
ний. Версионность документов позволяет поднять историю проведен-
ных изменений.
Ролевой подход к управлению проектами позволяет определить
необходимый объем прав для каждого участника системы. Гибкая сис-
тема настройки профилей безопасности, назначение лицензий на право
запуска модулей и приложений, определение доступа до уровня WBS
позволяет организовать одновременную работу в системе всех участни-
ков проекта, уменьшая продолжительность планирования за счет парал-
лельной работы участников в рамках нескольких процессов.
05.0 Управление содержанием проекта (Project Scope
Management)
Согласно PMBOK, план управления содержанием может быть как
неформальным и обобщенным, так и подробным. Он нужен для того,
чтобы определить, как именно команда проекта будет формулировать
содержание проекта, разрабатывать WBS, проверять и контролировать
содержание проекта. Это включает в себя описание, как инструментов и
методов, так и последовательности операций (работ). В Primavera мож-
но вести отдельный график, включающий последовательность опера-
ций, для обеспечения контроля над осуществлением работ в этой облас-
38
ти знаний. Тогда работы по управлению содержанием проекта будут за-
креплены за членами команды проекта. Они смогут отчитываться в вы-
полнении этих работ, и руководитель проекта, во-первых: будет всегда
уверен в том, что проект не отклоняется от заданного содержания; во-
вторых: сможет видеть занятость команды проекта.
Для согласования, утверждения и хранения плана управления со-
держанием используются функции портала системы. Участники подго-
товки плана содержания ведут обсуждения возникающих вопросов на
форуме портала с публикацией и ознакомлением с результатами всех
участников в новостях и событиях проекта.
Результат анализа потребностей, пожеланий и ожиданий участни-
ков проекта, которые потом преобразуются в требования, могут быть
зафиксированы в отдельном документе, который прикреплен к проекту.
Утвержденные в рамках этого процесса требования, допущения и огра-
ничения по проекту могут также вноситься непосредственно в график
проекта. Подробное описание содержания проекта (цели проекта, опре-
деление содержания продукта, требования, ограничения проекта и до-
пущения, критерии приемки продукта) можно опубликовать на статиче-
ском сайте проекта из Primavera.
В последствии это позволит всем участникам проекта, в том числе
и "Заказчикам", проводить постоянный оперативный анализ соответст-
вия содержания проекта заданным целям и требованиям (см. подробнее
процесс 5.4).
Для автоматизации процесса целесообразно использовать сохра-
ненные типовые WBS из корпоративной базы типовых фрагментов про-
ектов. Используя мастер создания WBS, пользователь выбирает: ис-
пользовать целиком шаблон WBS проекта или сконструировать собст-
венный, выбрав только необходимые узлы WBS из шаблона. Распреде-
ление прав доступа по узлам WBS позволяет непосредственно ответст-
венным декомпозировать свой уровень WBS, используя клиент-
серверные или веб-приложения.
Primavera позволяет создавать многоуровневую WBS; за каждым
уровнем закреплять ответственного; проводить распределение бюджета
сверху-вниз; выбирать метод расчета процента выполнения для узла;
привязывать документы к WBS; прикреплять заметки; добавлять необ-
ходимую информацию в пользовательские поля; графическими индика-
торами обозначать состояние узлов WBS.
Использование кодов работ (настраиваемых линейных или иерар-
хических справочников) позволяет поддерживать в системе множество
различных структур. Группируя информацию по глобальным или про-
ектным кодам работ, вы представляете перечень работ в необходимых
разрезах. Используя веса узлов WBS, вы определяете соотношения объ-
39
ема работ между узлами WBS одного уровня. Это позволяет проводить
оценку сверху-вниз для распределения трудозатрат по проекту, соглас-
но определенной сложности каждого из пакетов работ в WBS.
06.0 Управление сроками проекта (Project Time Management)
Планировщики и технологи получают разные инструменты опре-
деления состава работ, используя клиент-серверные приложения, веб-
приложения и модули импорта данных из других систем. При опреде-
лении состава работ целесообразно использовать корпоративную базу
типовых фрагментов проектов, содержащую: перечень работ, WBS, на-
значения расходов, ресурсов, ролей и результатов работ. В мастере ис-
пользования шаблона вы задаете сложность текущего проекта для авто-
матического корректирования типового фрагмента под требования и ус-
ловия вашего проекта. Архив проекта, хранящийся в единой базе дан-
ных, позволяет обращаться к предыдущим проектам, получая необхо-
димую информацию и использовать её для планирования новых проек-
тов.
Более детальное разбиение работ на несвязанный список субопе-
раций в Primavera производится с использованием механизма шагов ра-
бот. У вас есть возможность создать шаблоны шагов для разных типов
работ, в том числе используя их как контрольный список задач в рамках
одной операции. Для каждого шага задается его вес относительно всего
объема операции. Расчет процента выполнения по работе может произ-
водиться по фактическому выполнению шагов работы.
Для создания графиков также используется работа типа "гамак",
которая объединяет группу операций, определяя общую продолжитель-
ность всех связанных с ней работ. Это позволяет использовать инфор-
мацию с детальных графиков проведения работ для предоставления
сводной информации руководству. С этой же целью можно использо-
вать работы типа «Суммарная WBS», автоматически агрегирующие ин-
формацию по срокам и процентам выполнения по всем работам уровня
WBS и позволяющие автоматически получить актуальный укрупненный
график.
Primavera поддерживает Precedence Diagramming Method (Диа-
грамма “операции в узлах”) и все четыре типа зависимостей «финиш-
старт», «финиш-финиш», «старт-старт», «старт-финиш», а также воз-
можность фиксирования опережений и задержек (PMBOK п.6.2.2.5) для
создания Сетевой диаграммы с учетом технологии, ограничений и до-
пущений проекта. Для назначения зависимостей между работами ис-
пользуется отображение диаграммы Гантта с набором работ, форма ра-
боты или специализированное представление, реализующее диаграмму
"работы в узлах" – логическую диаграмму работ. Планировщики полу-
40
чают возможность отображения на одном экране логической диаграм-
мы, диаграммы Гантта и таблицы работ со списком работ и их необхо-
димых параметров.
Наличие единой базы данных проектов позволяет установить за-
висимости между проектами, связывая их в программы и мегапроекты.
При расчете расписания выбранные настройки указывают, учитывать
влияние работ других проектов и программ по межпроектным зависи-
мостям или нет.
Используя базу методологий, вы можете создавать проекты или
изменять содержание существующих проектов, используя сохраненные
типовые фрагменты с уже назначенными зависимостями между работа-
ми.
В Primavera все ресурсы организации записаны в едином справоч-
нике, представленном в виде иерархической структуры. Среди атрибу-
тов ресурса указывается допустимая интенсивность его использования в
часах (для трудовых и нетрудовых ресурсов – соответственно людей и
оборудования) или в других заданных величинах (для материалов).
Трудовые и нетрудовые ресурсы могут иметь от одной до нескольких
ролей. Иначе говоря, роль - это специальность. Для каждого ресурса
можно вести свой отдельный календарь, в котором будет учтена персо-
нальная предельная загрузка.
Единый справочник ресурсов необходим для определения доступ-
ности ресурса для назначения на операции проекта. При этом пользова-
тель получает информацию по подневной/почасовой загрузке, список
назначений ресурса на другие работы, информацию о том, насколько он
загружен по сравнению с его пределом потребления, в том числе и в
других проектах. Информация может отображаться как в табличном,
так и в графическом виде. Отчеты, показывающие загрузку ресурсов,
могут иметь различный уровень детализации, начиная с информации по
отдельному сотруднику и заканчивая комплексной информацией по
фактическому и планируемому использованию ресурсов компании.
На ранних фазах проекта можно планировать потребности в необ-
ходимых ролях (специальностях) для выполнения работы. Если указан
необходимый уровень квалификации, то автоматически будут отфильт-
рованы только те ресурсы, которые обладают требуемой компетенцией.
При создании графика на основе корпоративной базы типовых
фрагментов проектов Primavera корректирует длительности работы на
основании введенной вами сложности проекта. Под сложностью проек-
та понимается рассчитанный исходя из выбранных условий проекта ко-
эффициент изменения фрагмента по длительности, трудозатратам и
стоимости работ. Выполненные проекты служат основой для оценки
минимальных и максимальных значений длительности, ресурсоемкости
41
и стоимости работ в типовом фрагменте. В зависимости от выбранного
типа работы Primavera позволяет учитывать или не учитывать измене-
ния назначений ресурсов на работу для оценки ее длительности.
Это автоматический процесс, определяющий сроки выполнения
проекта, с учетом того, что уже есть список работ, определены зависи-
мости, назначены ресурсы и рассчитаны (заданы) длительности работ. В
результате пользователь получает расписание проекта, рассчитанное по
методике критического пути. Отображение расписания в Primavera свя-
занно с временной шкалой, которую пользователь настраивает в соот-
ветствии со своими потребностями (день/неделя, неделя/месяц, ме-
сяц/квартал и т.д.). При расчете можно определять не только критиче-
ский или самый длинный путь, но и околокритические пути проекта,
которые нужны для определения работ, требующих более пристального
контроля во время исполнения проекта.
В результате пользователь формирует целевой (базовый) план
проекта, который будет служить основой для дальнейшего контроля па-
раметров проекта. Primavera позволяет сохранять неограниченное коли-
чество целевых планов для каждого проекта. Так вы можете создавать
целевые планы в ходе процесса реализации проекта, сравнивая текущий
график и с первоначальным целевым планом, и с предыдущим целевым
планом. Это позволяет увидеть тенденцию и сделать выводы относи-
тельно эффективности управления текущим проектом. Механизм об-
новления целевых планов позволяет упростить процесс внесения изме-
нений в проект.
Определив приоритеты (по проектам, работам, исходной длитель-
ности и т.д.), можно провести автоматическое выравнивание ресурсов.
Оно позволяет определять последовательность работ с учетом ресурс-
ных ограничений и потребности в ресурсах в различных проектах.
Девять типов ограничений на сроки работы позволяют учесть ог-
раничения, прописанные в контракте, наличие «рыночного окна», бла-
гоприятные погодные условия, требования спонсоров, сроки поставки
оборудования от поставщиков, не учитываемых в графике, и т.д.
В разделе Контроль представитель Офиса управления проектами
может проводить анализ «что-если», проводя планирование сроков про-
ектов для разрешения конфликтов ресурсов.
Другим механизмом анализа «что-если» является вывод на диа-
грамму Гантта одновременно информации по 3 целевым планам для
проведения анализа, контроля или сравнения.
07.0 Управление стоимостью проекта (Project Cost Management)
В процессе планирования проекта одной из основополагающих за-
дач является оценка и анализ стоимости проекта. В Primavera стоимость
42
ведётся в двух сущностях: 1) в виде назначения ресурса/роли на работу;
2) в виде назначения фиксированных расходов на работу (например, на-
кладные расходы, расходы по получению разрешений и т.п.) Все расхо-
ды могут быть классифицированы по структуре Статей затрат. Согласно
PMBOK для проведения стоимостной оценки можно использовать сле-
дующие методы.
Метод "оценки по аналогам" позволяет при оценке стоимости ис-
пользовать данные по реализованным ранее и сохраненным в базе мето-
дологий проектам. Это позволяет использовать опыт фактической реа-
лизации предыдущих проектов. Тесно с ним связан и метод "парамет-
рической оценки". Используя мастер по работе с Базой методологий, вы
самостоятельно определяете сложность текущего проекта, что позволя-
ет получить из параметрического шаблона более точную оценку стои-
мости работ текущего проекта.
Для использования метода "определения ставок стоимости ресур-
сов" в словаре ресурсов вы задаете изменяющиеся по периодам времени
набор расценок ресурса (максимально до 5 расценок на каждый ресурс).
При назначении ресурса на работу можно, как выбрать одну из этих пя-
ти ставок, так и определить собственную на данном назначении ресурса
на работу. Стоимость назначения будет рассчитываться исходя из за-
данного количества использования ресурса и расценки, либо вы можете
использовать фиксированную стоимость назначения. В случае измене-
ния ставок в словаре ресурсов можно провести синхронизацию расце-
нок словаря ресурсов и назначений ресурсов на работы.
Руководитель проекта или ответственный за пакет работ (уровень
WBS) может применять метод "оценки снизу вверх" для просмотра
сводной информации по уровням в зоне своей ответственности, соглас-
но правам доступа. Хранение и работа с проектами в единой базе дан-
ных позволяет видеть на каждом уровне всю агрегированную информа-
цию со всех включенных в него подуровней. Информация по уровням
является расчетной, суммированной по более детальным элементам, что
обеспечивает требования к прозрачности, точности и отсутствия двой-
ного ввода для разных уровней. В свою очередь в Primavera существует
проектное бюджетирование сверху вниз, где определяется бюджет для
узлов Структуры проектов предприятия, проектов и уровней WBS и ве-
дется журнал изменения бюджета. После утверждения бюджета на
верхнем уровне вы распределяете этот бюджет на ниже стоящие уров-
ни, контролируя показатель Нераспределенный бюджет. После прове-
дения оценок снизу вверх можно проводить сравнительный анализ вы-
деленных бюджетов и оценки стоимости представленной "снизу". Про-
водя итерационные процессы согласования и утверждения бюджетов
проектов совместно с проведением бальной оценки проектов по дости-
43
жению стратегических целей организации, вы сможете подготавливать
и утверждать наиболее оптимальный набор проектов на будущий пери-
од.
Для обеспечения этого процесса в Primavera существует автомати-
ческое суммирование стоимостных оценок отдельных работ до узлов
WBS и уровня проекта. Ведение резервов для непредвиденных событий
может вестись в виде Нераспределенного бюджета, с одной стороны не
включаемого в базовый план, а соответственно не участвующего в ана-
лизе освоенного объема, с другой стороны это позволяет руководителю
проекта постоянно контролировать свободный доступный нераспреде-
ленный резерв бюджета для проекта. Эти ограничения доступны для со-
гласования в виде журнала бюджета, что позволяет проводить рассмот-
рение изменений и хранение их истории. В Primavera существует воз-
можность сформировать план финансирования проекта с разбивкой по
месяцам и указанием источников финансирования - это осуществляется
как для уровня проекта, так и для каждого уровня структуры WBS, с
возможностью построения кривой ROI. Модель бюджета по расходам с
разбивкой по месяцам может быть в свою очередь передана в финансо-
вую систему или наоборот – получена из нее.
Анализ стоимостей в Primavera можно проводить в разных валю-
тах. Пользователи самостоятельно выбирают валюту для отображения
стоимостной информации в одной из настроенных администратором
системы валют. Результатом этого процесса является базовый план по
стоимости, который, как и рекомендуется в PMBOK, нагляднее пред-
ставить в виде S-кривой, либо в виде таблицы.
08.0 Управление качеством проекта (Project Quality Management)
Инструменты процесса планирования качества должны обеспе-
чить участников проекта информацией о мероприятиях по управлению
качеством и предоставить данные для анализа наилучшей стратегии
достижения требуемого уровня качества. При проведении планирования
качества в Primavera, вы используете весь функционал по определению
состава работ, оценке стоимости, используете процессы согласования
для достижения требуемого уровня качества проекта, находясь в балан-
се с остальными критериями проекта: сроками, стоимостью и содержа-
нием.
Согласно PMBOK, используются следующие инструменты и ме-
тоды:
Анализ прибыли и затрат - проводя анализ по методике «что-
если», используя управление рисками, можно получить взвешенное ре-
шение о необходимости проведения тех или иных работ по повышению
44
качества за счет больших вложений на первоначальном этапе, что по-
зволит снизить затраты уже в ходе эксплуатации.
Бенчмаркинг - отчеты по работам других проектов, как связанным
с управлением качеством, так и по прочим. Дают полезную информа-
цию для принятия решений по усовершенствованию деятельности.
Планирование экспериментов - вводится набор работ по проведе-
нию экспериментов. По результатам этих работ проводится согласова-
ние необходимости проведения перепланирования графика, если в про-
екте возникают существенные изменения.
Стоимость качества (СК) – в Primavera можно вести работы по
контролю либо повышению качества. При этом стоимостная оценка
этих работ относится на статьи затрат по управлению качеством, что
позволит подготовить для руководства отчет по стоимости работ по ка-
честву, в частности, по доли этих работ в общей стоимости проекта.
Дополнительные инструменты управления качеством - в качестве
дополнительного инструмента управления качеством необходимо отме-
тить портал проекта, позволяющий собирать всех участников, всю ин-
формацию и все мнения по проекту с момента его инициации до закры-
тия, в дальнейшем обращаясь к этим данным в процессе анализа.
Далее:
Разрабатывается план управления качеством, который может быть
включен как дополнительные работы в основной проект, так и быть до-
полнительным субпроектом с межпроектными связями. При возможно-
сти унификации работ по управлению качеством - эти работы можно
поместить в корпоративную базу методологий для автоматизации их
использования.
Планируется, как будет производиться оценка результатов управ-
ления качеством – это может быть формализованная процедура, по ко-
торой работа завершается только после согласования ее результатов по-
следующим ответственным за выполнение, что учитывается в процессе
приемки работ. Это позволит сократить претензии со стороны исполни-
телей на некачественную предшествующую работу, вовлекая их еще на
стадии выполнения. Кроме того, определяются формальные критерии,
которые позволят оценить степень достижения заданного уровня каче-
ства. Если эти критерии связаны, например, со сроками или стоимо-
стью, то в Primavera можно настроить показатели и задать их пороговые
значения. В последствии в процессе контроля можно следить за измене-
нием значений показателей.
Для ведения контрольных списков процедур контроля качества в
Primavera можно использовать шаги работ. Разработав стандартные
шаблоны этапов проверки качества и используя их, вы будете уверены,
45
что каждая работа пройдет формальный процесс оценки качества вы-
полнения.
При разработке плана совершенствования процессов управления
качеством в Primavera возможно создавать отдельные рабочие группы
по проекту, в которых объединяются участники, непосредственно отве-
чающие за тот или иной процесс.
При необходимости согласования любых изменений в плане
управления качеством используются процессы общего управления из-
менениями (раздел 4.6).
09.0 Управление человеческими ресурсами (Project Human
Resource Management)
Для обеспечения этого процесса Primavera позволяет: определять,
какие роли будут задействованы в проекте; распределять ответствен-
ность и разрабатывать план управления обеспечением проекта персона-
лом. Для этих целей используются следующие иерархические структу-
ры: WBS, разработанная в разделе 5.3; Организационная структура или
структура ответственных, содержащая перечень сотрудников и отделов,
отвечающих за выполнение работ в проектах; иерархические структуры
ресурсов и ролей, используемые для ведения единых справочников всей
организации (более подробно в разделе 6.3).
На выходе процесса в Primavera содержится: назначение ролей,
требуемых для выполнения работ проекта, с информацией о требуемой
квалификации; определенными полномочиями и ответственностью;
проведено распределение ответственных за работы.
При разработке плана управления обеспечением проекта персона-
лом Primavera автоматизирует следующие процессы:
Набор персонала - единый корпоративный справочник ресурсов
организации позволяет проводить анализ «что-если», по критериям дос-
тупности и стоимости вариантов назначений ресурсов. На портале про-
екта происходит самоорганизация взаимодействия подрядных органи-
заций без строгой необходимости вмешательства управляющей компа-
нии.
Расчет расписания – укрупненное планирование ресурсов буду-
щих периодов; детальное назначение ресурсов на работы, с динамиче-
ским анализом загрузки ресурса по всем проектам организации, с ото-
бражением кривой доступного предела по потреблению ресурса. В
Primavera существует отдельный раздел по назначению ресурсов на ра-
боты с возможностью анализа в табличной форме по периодам времени.
Планирование загрузки ресурсов - планирование общей потребно-
сти в персонале и загрузки его на всех проектах, особенно для органи-
заций, ориентированных на масштабные проекты, например судострои-
46
тельные, для выравнивания «пиков» перегрузки или «провалов» при от-
сутствии заказов.
Обучение персонала - предварительное планирование проекта с
ролями позволяет определить и подготовить отчет по требуемым специ-
альностям с квалификацией. Это может послужить основанием для про-
ведения дополнительного набора и обучения персонала перед началом
выполнения проекта.
Поощрение и премирование - разработка системы мотивации на
основе достижения результатов в проектах позволяет предоставить уча-
стникам четкие правила и критерии их успешной работы. Информиро-
вание всех исполнителей через публикацию графика проекта позволяет
повысить ответственность персонала, давая осознание важности каждой
отдельной работы для всего проекта в целом. Отчеты, публикация веб-
сайта проекта расширяют круг участвующих в неформальном контроле
результатов проекта.
Соответствие - ведение индивидуальных календарей ресурсов по-
зволяет привлекать ресурсы в соответствии с требованиями законода-
тельства и профсоюзов.
Безопасность - включение в график пакетов работ по контролю
соответствия проекта нормам техники безопасности. Во время выпол-
нения проекта функциональные возможности Primavera позволяют ре-
гистрировать и готовить отчеты по фактам нарушения техники безопас-
ности.
10.0 Управление коммуникациями проекта (Project Communication
Management)
Primavera предлагает законченное решение, содержащее в базовом
функционале инструменты для создания среды взаимодействия между
участниками проекта: портал, форумы, заметки, центр коммуникаций,
извещения, веб-сайт проекта, отчеты и макеты. Primavera отвечает сле-
дующим требованиям по обмену информацией:
• актуальности и своевременности предоставления необходимой
информации, все участники совместно работают в единой системе;
• доступности технологий для персонала проекта, Primavera - это
продуманное решение, обладающее интуитивно понятным интер-
фейсом;
• современности технологий, набор клиент-серверных, веб-
приложений, ПО для сбора данных по электронной почте позволяет
решать любые задачи распределенного взаимодействия участников.
Используя вышеперечисленный инструментарий Primavera, нет
необходимости уделять время на составление подробного плана управ-
ления коммуникациями. Данный функционал позволяет сосредоточить
47
усилия на других областях знаний, решая одну из главных задач — ор-
ганизации своевременного получения требуемой информации из систе-
мы всеми её участниками в соответствии с их ролями.
11.0 Управление рисками проекта (Project Risk Management)
В процессе планирования управления рисками проводится проце-
дура определения методологии, которая будет использоваться в данной
области знаний, распределяются ответственные по ролям, определяются
категории рисков и т.д. На этом этапе основная задача команды проекта
- определить подходы и инструменты управления рисками и т.д.
Primavera обеспечивает поддержку процесса обсуждения возникающих
вопросов на форуме портала проекта. Возможно привлечение внешних
по отношению к проекту консультантов по рискам на портал проекта,
для принятия участия в обсуждении, планировании мероприятий и со-
гласовании решений по управлению рисками.
Пользователь может создавать шаблоны извещений для проекта с
выбранными категориями рисков по данному проекту, прикреплять к
ним выбранные отчеты и другие необходимые документы к проекту.
На основе информации, собранной в ходе процесса планирования,
производится идентификация рисков и их фиксация для детального рас-
смотрения и анализа. Это итеративный процесс.
В ходе идентификации, согласно PMBOK, проводится анализ ар-
хива выполненных проектов и отклонений в них, и рассмотрение архива
документов по анализу рисков. Все документы, которые разработаны во
время процесса сбора информации, результаты контрольных списков,
анализ допущений могут быть прикреплены к соответствующим эле-
ментам проектов (работам или элементам WBS).
Все идентифицированные риски вводятся в систему с описанием,
как самого риска, так и мероприятий по контролю рисков. Затем они
передаются на следующий этап для их качественного анализа.
В ходе качественного анализа рисков в системе определяются
приоритеты и важность рисков для дальнейшего анализа. Это требуется
для повышения эффективности проведения анализа рисков, т.к. позво-
ляет сосредоточить усилия на рисках, обладающих наивысшим приори-
тетом. Извещения, которые создаются в ходе анализа рисков, должны
быть кодированы на основании вероятности их возникновения, влияния
на достижение целей проекта в случае их возникновения и с учетом ря-
да других факторов (например, временных рамок и толерантности к
риску, заложенной в ограничениях проекта по стоимости, срокам, со-
держанию и качеству). Результаты качественного анализа используются
и специализированным программным продуктом для анализа рисков
48
Pertmaster (работающим с Primavera) в ходе создания имитационной мо-
дели проекта (раздел 11.4).
Количественный анализ производится в отношении тех рисков,
которые в процессе качественного анализа рисков были квалифициро-
ваны как потенциально существенно влияющие на свойства проекта.
При количественном анализе рисков в Primavera можно рассчи-
тать, какие последствия будет иметь тот или иной идентифицированный
риск. Введя определенное экспертами увеличение трудозатрат и/или
расходов с заданной вероятностью, мы рассчитываем, как этот риск по-
влияет на результаты проекта в стоимостном выражении и в задержке
сроков проекта.
C использованием Pertmaster график работ может быть промоде-
лирован по методике Монте-Карло. Это позволяет получить расчет ве-
роятности распределения по различным показателям: стоимости, трудо-
затратам, срокам. Имитационное моделирование рисков по методике
Монте-Карло требует создания оптимистического, пессимистического и
наиболее вероятного сценариев. Вместе с этими расчетами проводится
анализ чувствительности, результатом которой является диаграмма тор-
надо, позволяющая определять риски с наибольшим потенциальным
влиянием на проект.
Результаты количественного анализа рисков могут быть сохране-
ны в системе, среди них:
• вероятностный анализ проекта - график кривой распределения ве-
роятности по различным показателям;
• вероятность достижения целей по стоимости и времени, что являет-
ся основой для анализа способности достигнуть поставленных це-
лей проекта при текущих плановых значениях;
• список приоритетных оцененных рисков - список наиболее значи-
мых рисков, который определяется на основе диаграммы торнадо;
• тренды результатов количественного анализа рисков - сохранение
результатов проведения анализа рисков, что позволит следить за
тенденциями в процессах достижения целей проекта.
Согласно PMBOK, планирование реагирования на риски - это про-
цесс разработки путей и определения действий по увеличению возмож-
ностей к снижению угроз для целей проекта. В ходе проведения анализа
в извещениях по рискам указываются ответственные лица по контролю,
отслеживанию и снижению вероятности их возникновения.
При проведении Стратегии реагирования на негатив-
ные/позитивные риски (угрозы/благоприятные возможности), в ходе
Уклонения, Передачи, Снижения, Использования, Совместного исполь-
зования и Усиления результатом является план пересмотра графика вы-
полнения проекта. В него входит изменение содержание, состава работ,
49
назначения ресурсов и стоимостей с целью снижения неблагоприятного
воздействия на результаты проекта. Предварительным шагом может
быть проведение анализа «что-если», его документирование, согласова-
ние и утверждение. Возможность выделить с помощью системы кодов
такие изменения в проекте позволяет каждому участнику просматривать
план реагирования на все или отдельно только на какие-то определен-
ные риски. Такая информация становится базовой при последующих
итерациях группы процессов планирования с целью получения предло-
жений со стороны участников.
12.0 Управление поставками проекта (Project Procurement
Management)6
Данные о закупках в систему вводятся на основании заказных
спецификаций. После заполнения общих сведений о принадлежности
заказной спецификации, заносится перечень товарно-материальных
ценностей, вошедших в заказную спецификацию. По каждой позиции
МТР заказной спецификации можно вести плановые данные поставок.
На основании заказных спецификаций формируются комплектовочные
ведомости, для каждой позиции которой проводится операция распре-
деление поставок между Субподрядчиком и Ген. Подрядчиком. Для
обеспечения детального управления поставками может потребоваться
применение специализированных дополнительных модулей.
На портале проводится обсуждение и предквалификация исполни-
телей по поставке. На основании разделительных ведомостей подготов-
ляются отчеты, содержащие перечень необходимых материалов и обо-
рудования с требуемой разбивкой по типам. Эта данные формируются в
Запрос информации и отправляются продавцам. Для обеспечения де-
тального управления договорами может потребоваться применение спе-
циализированных дополнительных модулей.
3.3. Группа процессов Исполнения
04.0 Управление интеграцией проекта (Project Integration
Management)
Наличие единой площадки по вводу, анализу и хранению данных
по проекту позволяет соединить деятельность в рамках всех процессов,
обеспечивая необходимый уровень руководства и управления исполне-
нием проекта. Независимо от месторасположения и условий может быть
разработан организационный и технический план управления проектом
6
В области знаний по Управлению поставками проекта вместе с Primavera рассматриваются разработанные
для неё интегрированные приложения по ведению договорного процесса с поддержкой принятых в России
правил и процедур.
50
на базе комплекса средств, предлагаемых Primavera и интегрированных
с ней модулями от других разработчиков. Удаленный доступ к системе;
одновременная работа с календарно-сетевым графиком проекта с уче-
том ролевого доступа; осуществление сбора данных и актуализации
графика в режиме постоянного подключения или сбора данных с помо-
щью электронной почты; организация различных вариантов работы с
субподрядчиками в рамках единого графика; поддержка задач ведения
графиков различного уровня детализации – это те задачи, которые по-
зволяет решить Primavera. Различные средства по актуализации плана
проекта позволяют выбирать наиболее удобный инструмент в каждом
случае, экономя время и снижая вероятность появления ошибок при
вводе информации.
08.0 Управление качеством проекта (Project Quality Management)
В процессе исполнения в Primavera доступны следующие меха-
низмы контроля качества: использование запросов на изменение позво-
ляет проконтролировать, чтобы до окончания согласования были вы-
полнены корректирующие действия над графиком и внесены изменения
в документы/результаты проекта; отчет по работам, отмеченным для
исправления дефектов; список извещений с предупреждающими дейст-
виями. В этом процессе также используются средства, описанные в
Планировании качества (раздел 8.1) и Процессе контроля качества (раз-
дел 8.3).
09.0 Управление человеческими ресурсами (Project Human Resource
Management)
В процессе набора команды проекта участники, управляющие
проектом,
получают инструменты для управления назначением персонала.
Эти инструменты позволяют:
• Предоставить информацию о доступности ресурсов в реальном
времени на основании загрузки ресурса во всех проектах организа-
ции;
• Проводить назначение ролей с квалификацией на первоначальном
этапе планирования, а при заполнении ролей автоматически отби-
рать сотрудников из словаря ресурсов, отвечающих требованиям к
квалификации и специализации;
• Создавать отчеты из системы с данными об опыте работы сотруд-
ника, на каких проектах работал, какие работы выполнял;
• Вести двухсторонний обмен информацией, когда каждый сотрудник
получает уведомление о своем назначении на работу, может про-
сматривать список своих работ в персональном рабочем окружении
и вести обсуждения по работам с руководителем проекта;
51
• Выбирать для каждого назначения одну из сохраненных ставок ре-
сурса, либо вносить определенную ставку для конкретного назначе-
ния. Причем оценочная стоимость ресурсов проекта появляется еще
на первоначальной стадии планирования, на основе стоимости на-
значения ролей.
Инструменты совместной работы по проекту позволяют создавать
виртуальные команды, которые получают доступ к общей системе дан-
ных по проектам для просмотра и внесения изменений. Хранение и рас-
смотрение документов, централизованный механизм управления изме-
нениями, информирование всех участников по событиям проекта - это
механизмы, объединяющие участников территориально распределен-
ных команд.
В этом процессе основной упор делается на навыки общего ме-
неджмента при обучении персонала. Primavera в этом случае осуществ-
ляет необходимую информационную поддержку и планирование мероприятий по
развитию команды проекта.
10.0 Управление коммуникациями проекта (Project Communication
Management)
Информационная система управления проектами должна обеспе-
чить всех её участников оперативной, своевременной информацией.
Гибкая система распределения прав доступа, различные средства пред-
ставления информации (отчеты, макеты, веб-сайты проекта) и модуль-
ность системы позволяет решить эту задачу с помощью Primavera. Сис-
тема, создаваемая на базе Primavera, способна вовлечь в проект всех
участников от исполнителей до высшего руководства, предоставляя не-
обходимый уровень детализации, среза информации, согласно опреде-
ленным полномочиям и решаемым задачам.
12.0 Управление поставками проекта (Project Procurement
Management)
Запрос информации у продавцов подразумевает получение от
предполагаемых поставщиков ответов в виде предложений цены и зая-
вок на удовлетворение требований проекта. Полученный от них прайс-
лист может быть введен в реестр прайс-листов поставщиков. В рамках
системы могут проводиться тендеры со сравнением предложений от
каждого участника.
На основании полученных данных от продавцов проводится ана-
лиз предложений. Для выбранных исполнителей формируются договора
в системе на поставку материалов и оборудования. По каждому догово-
ру вводятся реквизиты сторон, условия, этапы договора. В приложении
к договору из перечня МТР создается спецификация к договору.
52
 Для ведения договорного обеспечения проекта могут быть исполь-
зованы модули в составе Primavera, либо специализированные интегри-
рованные модули, разработанные с учетом российской практики веде-
ния договоров. Работы проекта или уровни WBS могут служить основ-
ной для календарных планов к договорам, исходная стоимость выпол-
нения работ этапа отображается в календарном плане с разбивкой по
периодам времени. Можно вести номенклатурный справочник материа-
лов и оборудования с возможностью формирования полной комплекто-
вочной ведомости всех проектов и разделительных ведомостей. На ос-
нове комплектовочной ведомости формируются договоры со специфи-
кацией.
3.4. Группа процессов Мониторинга и управления
04.0 Управление интеграцией проекта (Project Integration
Management)
Поддержка процессов сбора и распространения информации об
эффективности выполнения; статические и динамические средства
представления данных для оценки результативности и тенденций: маке-
ты и отчеты, которые содержат текстовую и графическую информацию.
Средства контроля с помощью настраиваемых автоматических извеще-
ний; система показателей, которая позволяет идентифицировать про-
блему, что дает возможность руководителю проекта или ответственно-
му за выполнение спустится до проблемного уровня WBS, при необхо-
димости переходя в работы для более детального анализа причин от-
клонений. Осуществляется поддержка процесса сравнения текущего ис-
полнения проекта одновременно с тремя целевыми планами. Проводит-
ся всесторонний анализ проекта методом освоенного объема, расчет
возврата от инвестиций, сравнения с лимитами по бюджету.
Система для поддержки процессов изменений позволяет при иден-
тификации события, требующего рассмотрения, описать его, уведомить
и предоставить информацию для анализа и обсуждения участникам
проекта. Провести рассмотрение влияния изменения на сроки, трудоза-
траты и стоимости работ, в том числе, получить отчеты по отклонениям
от текущего утвержденного плана работ (целевого плана); предоставить
подробную информацию Руководству по влиянию изменений на проект;
сохранить историю изменений по проекту; провести процессы рассмот-
рения и утверждения изменений согласно разработанным шаблонам с
определенным количеством этапов и ответственных рецензентов.
В системе можно вести протоколы совещаний, сохраняя информа-
цию о сроках и ответственных за каждый из пунктов протокола. Систе-
53
ма напоминаний аккумулирует перечень требующих решения вопросов
и предупреждает об истечении сроков для своевременного исполнения.
05.0 Управление содержанием проекта (Project Scope
Management)
Primavera позволяет включить всех участников проекта в процесс
приемки результатов работ. Этот механизм необходимо использовать
при передаче результатов между подрядчиками, в первую очередь на
наиболее сложных задачах. Завершение работы может быть установле-
но только после проведения процесса согласования и аудита прини-
мающей стороны, что позволит сократить количество взаимных претен-
зий в виновности возникновения проблем в проекте. Информационная
система позволяет избежать предоставления заведомо неверной инфор-
мации при сквозной передаче результатов работ от исполнителей, повы-
сить ответственность исполнителей за счет прозрачности отчетности.
Результаты работ могут быть переданы в систему документооборота с
общим доступом через портал, а там уже доработаны, согласованы и ут-
верждены. Причем процесс рассмотрения начинается уже на стадии вы-
полнения, а не по фактическому финишу, что позволяет избежать воз-
никновения непредусмотренных графиком работ по корректировке не-
качественной работы. Также на портале проекта можно разместить изо-
бражение с веб-камеры с обзором площадки строительства, склада или
производственного цеха, что позволяет дополнительно контролировать
соответствие целей и требований проекта тому, что происходит в реаль-
ной действительности.
Primavera обеспечивает регистрацию и рассмотрение всех запро-
шенных изменений через утвержденную процедуру управлениям изме-
нениями. Процесс осуществляется с учетом уровней одобрения измене-
ний, а все входящие и результирующие документы прикрепляются к
процессам рассмотрения изменений. В результате этих операций сохра-
няется очередная версия проектных документов и обновляются компо-
ненты графика проекта.
06.0 Управление сроками проекта (Project Time Management)
Для эффективного управления расписанием необходимо автомати-
зировать следующие подпроцессы/области:
Отчетность о прогрессе проекта. Для актуализации данных в Pri-
mavera существуют различные инструменты для автоматического ввода
данных по прогрессу в проекте. Для ИТ, консалтинговых компаний и
проектных институтов средством отчетности является табель, в котором
отчитывается каждый сотрудник, заведенный в системе как трудовой
ресурс. В табеле сотрудники ежедневно заполняют отработанное время
54
по той или иной работе, с возможностью указания сверхурочной рабо-
ты. После представления в конце отчетного периода табель проходит
одно- или двухуровневое согласование руководителя проекта и функ-
ционального руководителя. Утвержденное время автоматически попа-
дает в расписание проекта как факт.
Средством сбора фактических данных без необходимости посто-
янного подключения к базе данных Primavera выступает PMExchange.
Он позволяет выгружать по фильтру работы определенного подрядчика
за отчетный период. Отсылая по электронной почте исполнителю план
работ на текущий период , вы собираете в ответ актуальную информа-
цию по этим работам с введенным фактическим исполнением по ресур-
сам, расходам и шагам работ. Руководитель проекта с учётом информа-
ции от куратора проводит предварительный анализ присланных данных
и при соответствии автоматически вносит их в график.
Кроме всех перечисленных вариантов, также можно вносить фак-
тическую информацию непосредственно в каждую операцию проекта в
одном из модулей Primavera. При этом допускается ввод факта по: %
выполнения, физ.объемам, по срокам, по расходу ресурсов, по затратам.
Инструмент луч позволяет отфильтровать работы за выбранный
период времени и для выбранных работ применить фактическое выпол-
нение в соответствии с плановыми значениями.
Система управления изменениями расписания. Primavera поддер-
живает разграничение прав к вводу и утверждению фактической ин-
формации по проекту. Это позволяет с одной стороны включить в про-
цесс управления расписанием непосредственно ответственного за учет
выполнения, так и сократить вероятность внесения непроверенной или
неточной информации некомпетентными лицами. Ведется журнал из-
менений и есть возможностью настройки аудита событий в системе.
Измерения эффективности. В Primavera поддерживается измере-
ние эффективности посредством показателей освоенного объема и от-
клонениям по срокам. Различные модули Primavera позволяют вовлечь в
анализ эффективности всех - от исполнителей до высшего руководства,
повышая ценность данной управленческой информации в организации.
Методика освоенного объема, сравнение с тремя целевыми планами,
модуль портфели с разделом о состоянии проекта в виде системы инди-
каторов. Средства взаимодействия на портале позволяют опубликовать
и распространять необходимую информацию в единой среде для всех
заинтересованных лиц.
Отдельный раздел «Контроль» позволяет создавать макеты кон-
троля с детализацией до уровня WBS, подготавливая дополнительные
отчеты о выполнении проектов во временном, стоимостном и ресурсном
разрезах.
55
07.0 Управление стоимостью проекта (Project Cost Management)
Primavera позволяет вводить фактическую информацию по расхо-
дам в проекте, как в автоматическом, так и в режиме ручного ввода,
проводить анализ отклонений и оценивать влияние этих изменений на
общую стоимость. В рамках единой информационной среды взаимодей-
ствия на базе Primavera все ответственные и заинтересованные стороны
получают уведомления, если происходит изменения базового плана по
стоимости, что позволяет быстро реагировать на ситуацию по проекту и
контролировать затраты. Primavera поддерживает методику освоенного
объема, которая позволяет не только оценить текущую ситуацию, но и
спрогнозировать ее развитие. Кроме метода освоенного объема можно
использовать метод анализа отклонений и анализа тенденций (подроб-
нее см. PMBOK 7.3.2.4). Использование в этом процессе Primavera зна-
чительно сокращает время как на мониторинг ситуации (при этом Pri-
mavera идентифицирует проблему и причину ее возникновения), так и
на подготовку аналитических отчетов по проекту.
08.0 Управление качеством проекта (Project Quality Management)
В ходе процесса контроля качества проводятся различные работы
по анализу проекта. Все результаты фиксируются и прикрепляются на
сервер. Они служат основой для следующих мероприятий:
• Разработки и сохранения на сервере документа с результатами ме-
роприятий по контролю качества, переданные в рамках обратной
связи в отдел обеспечения качества (раздел 8.2) с целью повторной
оценки и проведения анализа стандартов качества и процессов, су-
ществующих в исполняющей организации.
• Подготовка отчета по работам с выявленными вопросами к качеству
исполнения.
• Проводится обновление базового плана по качеству (раздел 8.1).
• Определяются рекомендованные корректирующие действия и за-
пускаются процессы согласования и инициации изменений (раздел
4.6)
• Формируются извещения с предупреждающими действиями, рас-
сылаемые всем ответственным лицами.
Все зафиксированные данные сохраняются и прикрепляются к со-
ответствующим элементам проекта для возможности ретроспективного
анализа, в том числе и после закрытия проекта.
09.0 Управление человеческими ресурсами (Project Human Resource
Management)
Возможность ведения на портале открытой переписки по вопро-
сам проекта позволяет улаживать конфликты по проекту на предвари-
56
тельной стадии. Вовлечение команды в понимание целей проекта через
информирование о собственном вкладе каждого участника повышает
отдачу и эффективность работы. Члены команды проекта в качестве об-
ратной связи получают информацию об оценке их работы над проектом.
Механизм извещений может быть использован для создания журнала
регистрации проблем, в который заносятся и контролируются конфлик-
ты в команде проекта. Проведение рассмотрения этих проблем возмож-
но с использованием механизма управления изменениями.
Для решения вопросов с двойным подчинением функционального
и проектного руководителя при утверждении отработанного времени по
проекту, табель сотрудника утверждают, как руководители всех проек-
тов, в которых он принимал участие, так и функциональный менеджер.
10.0 Управление коммуникациями проекта (Project Communication
Management)
Отчетность по исполнению содержит сравнение данных целевых
планов с фактической информацией, содержащее, в том числе, и анализ
освоенного объема. Наличие неограниченного количества целевых пла-
нов, возможности одновременного сравнения на графике трех целевых
планов и анализ в табличной форме отклонений от целевых планов по-
зволяет участникам получить отчетность с требуемым содержанием,
формой и степенью детализации. Primavera предлагает следующие ин-
струменты: макеты, со столбиковыми и горизонтальными диаграммами,
S-кривыми, гистограммами, таблицами; настраиваемые html и excel-
отчеты; веб-сайт проекта; панель индикаторов для сводного портфель-
ного анализа; диаграммы раздела контроля для руководства всех уров-
ней.
Для взаимодействия и управления участниками проекта в Prima-
vera используется портал. На нем собирается информация о потребно-
стях, целях и задачах участников. Рабочее окружение проекта и выде-
ленные рабочие группы позволяют аккумулировать информацию с воз-
можностью доступа к ней из любой точки мира, в соответствии с опре-
деленными правами доступа. Через систему извещений распространя-
ются задачи, и ведется журнал регистрации проблем. Процесс управле-
ния изменениями позволяет запускать на рассмотрение извещения, что
исключает наличие неучтенных или нерешенных проблем в проекте.
11.0 Управление рисками проекта (Project Risk Management)
Для мониторинга и контроля риск-менеджер или руководитель
проекта может руководствоваться следующими источниками:
• Разработанным планом управления рисками, хранящимся в системе.
57
• Реестром рисков: список рисков в основном модуле; извещения по
проекту; список работ, по которым назначались дополнительные
резервы.
• Одобренными запросами на изменения, которые хранятся в качест-
ве результирующих документов согласования.
• Информацией об исполнении работ, с возможностью проведения
сравнения фактических данных с целевым планом. В частности, от-
дельному контролю подвергаются работы, для которых назначались
дополнительные резервы по трудозатратам и стоимости.
• Отчетами из системы. Они позволяют предоставить информацию
большему кругу участников проекта и не требуют при этом исполь-
зования дополнительных лицензий и знаний по работе с ПО. Набор
таких отчетов может содержать: реестр рисков, отчеты по влиянию
каждого риска на проект, отчеты из Pertmaster.
В ходе мониторинга проводится идентификация новых рисков в
проекте. По всем рискам проводится аудит и вводится текущий статус.
По результатам расчетов вероятности событий сохраняются контроль-
ные значения, и проводится анализ трендов за всё время выполнения
проекта. На основании отчетов о выполнении проекта проводится тех-
ническое измерение исполнения. Производится анализ резервов, вклю-
чающий, как оценку нераспределенного бюджета для направления, так
и анализ расходования резервов по работам с дополнительными резер-
вами. Это производится с целью принятия решения о целесообразности
проведения согласования выделения дополнительных резервов. Прово-
дятся дополнительные совещания на портале по анализу выбранной
стратегии и увеличения вероятности достижения целей проекта.
12.0 Управление поставками проекта (Project Procurement
Management)
Менеджер по договору получает всю необходимую информацию
по состоянию договора в одном рабочем окне. Актуальная информация
позволяет восстановить целостную картину выполнения подрядчиком
работ, увидеть финансовые параметры выполнения договора, контроли-
ровать спецификацию поставляемой номенклатуры товаров.
По заключенным договорам из системы формируются счета. Ве-
дется учет прихода и списания материалов и оборудования на складах
оформляемый: приходной и расходной ведомостью, актами передачи
под монтаж, документами по перемещению по складам.
58
 3.5. Группа процессов Закрытия7
04.0 Управление интеграцией проекта (Project Integration Man-
agement)
Завершение проекта служит началом подготовки требуемых отче-
тов из системы для анализа результативности выполненного проекта. В
системе производится архивирование проекта согласно разработанному
регламенту с возможностью доступа к нему при планировании будущих
проектов. Проводится оценка потребности в разработке типовых фраг-
ментов или внесения изменений в существующие фрагменты на основа-
нии актуального графика выполнения.
12.0 Управление поставками проекта (Project Procurement
Management)
Закрытие контракта и соответственно проекта заканчивается фор-
мированием отчета по реестру выполненных договоров по проекту и
переносом договора в архив.

Таким образом, показано, как Primavera позволяет использовать

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

7
Раздел3. написали С.Г. Киселев, С.В. Садовников, Е.О. Пужанова

59

4. Состав информационной системы
Рассматривая информационную систему управления проектами,
выделяют ее состав (то из чего состоит ИС — элементы) и ее структуру
(связи между элементами). Так как ИС является сложной, то ее можно
описать более чем на одном языке (академик А.И. Берг). Одним из ос-
новных свойств ИСУП является делимость на подсистемы, которая
имеет достоинства с точки зрения ее разработки и эксплуатации, к ним
относятся:
• упрощение разработки и модернизации ИСУП в результате спе-
циализации групп проектировщиков по подсистемам;
• упрощение внедрения и поставки готовых подсистем в соответст-
вии с очередностью выполнения работ;
• упрощение эксплуатации ИСУ вследствие специализации работ-
ников предметной области.
Обычно выделяют функциональные и обеспечивающие подсисте-
мы. Функциональные подсистемы ИСУП информационно обслуживают
определенные виды деятельности экономической системы (предпри-
ятия), характерные для его структурных подразделений и (или) функций
управления. Интеграция функциональных подсистем в единую систему
достигается за счет создания и функционирования обеспечивающих
подсистем, таких как информационная, математическая, техническая,
организационно-правовая и кадровая подсистемы.
4.1. Функциональные подсистемы информационных
систем управления проектами
4.1.1. Принципы формирования функциональных подсистем.
Функциональная подсистема ИСУП представляет собой комплекс
задач с высокой степенью информационных обменов (связей) между за-
дачами. При этом под задачей будем понимать некоторый процесс об-
работки информации с четко определенным множеством входной и вы-
ходной информации. Состав функциональных подсистем во многом оп-
ределяется особенностями компании, ее отраслевой принадлежностью,
формой собственности, размером, характером деятельности.
Функциональные подсистемы ИСУП могут строиться по различ-
ным принципам: предметному; функциональному; проблемному; сме-
шанному (предметно-функциональному).
Принципы предметной направленности использования ИСУП в
хозяйственных процессах промышленного предприятия определяются
соответствующими подсистемами управления производственными и
финансовыми ресурсами: материально-техническим снабжением, про-
60
изводством готовой продукции, персоналом, сбытом готовой продук-
ции, финансами. При этом в подсистемах рассматривается решение за-
дач на всех уровнях управления, обеспечивая интеграцию информаци-
онных потоков по вертикали. Для реализации функций управления вы-
деляют функциональные подсистемы: прогнозирование, нормирование,
планирование (технико-экономическое и оперативное), учет, анализ и
регулирование, которые реализуются на различных уровнях управления
и объединены в следующие контуры управления: маркетинг, производ-
ство, логистика, финансы.
Проблемный принцип формирования подсистем отражает необхо-
димость гибкого и оперативного принятия управленческих решений по
отдельным проблемам, например решение задач бизнес-планирования,
управления проектами. Такие подсистемы могут реализовываться в ви-
де локальных ИС, импортирующих данные из корпоративной информа-
ционной системы (например, система бизнес-планирования на основе
Project-Expert или Альт-Инвест), или в виде специальных подсистем в
рамках КИС (например, информационной системы руководителя).
На практике чаще всего применяется смешанный (предметно-
функциональный) подход, согласно которому построение функциональ-
ной структуры ИСУП — это разделение ее на подсистемы по характеру
хозяйственной деятельности, которое должно соответствовать структу-
ре объекта и системе управления, а также выполняемым функциям
управления. Используя этот подход, выделен следующий типовой набор
функциональных подсистем в общей структуре ИСУП предприятия,
реализованных в виде программных модулей.
4.1.2. Обзор программных средств управления проектами
Рынок программных средств управления проектами чрезвычайно
велик. Ниже приводится обзор наиболее распространенных в России
программ календарно-сетевого планирования Microsoft Office Project
2003, Spider Project, Welcom.
Microsoft Office Project 2003
Microsoft Project — широко распространенный в мире программ-
ный продукт для управления проектами. Начав с начального уровня,
рассчитанного на индивидуальную работу управляющего несложным
проектом, Microsoft Project, начиная с версии 2000, предпринимает ак-
тивные попытки завоевания корпоративного сектора рынка программ
управления сложным проектом. Процесс этот идет достаточно сложно,
в основном из-за серверных проблем, и по оценке Gartner Group по со-
стоянию на 2005 г. Microsoft Project находится лишь в секторе претен-
61
дентов на лидерство, отставая от группы лидеров, возглавляемых фир-
мой Primavera.
Настольное приложение Microsoft Project сочетает в себе интуи-
тивно-понятный интерфейс Microsoft Office и все необходимые менед-
жеру проекта средства для управления планом и ресурсами проекта.
Серверный продукт Microsoft Project Server является платформой
для организации корпоративной системы управления проектами и обес-
печивает коллективный доступ к проектной информации и взаимодей-
ствие участников проекта через Веб-интерфейс.
Семейство продуктов Microsoft Office Project 2003 состоит из сле-
дующих продуктов:
Microsoft Office Project Standard — настольное приложение для
индивидуального планирования и управления проектами. Использует
дружественный интерфейс Microsoft Office, что обеспечивает ускорение
освоения программы менеджерами проектов.
Microsoft Office Project Professional — настольное приложение,
исполняющее роль клиента в связке с сервером Microsoft Project Server.
Содержит всю функциональность Microsoft Project Standard и в связке с
Microsoft Project Server обеспечивает пользователей средствами корпо-
ративного управления проектами. Помимо традиционных средств пла-
нирования, менеджерам проектов предоставляются централизованные
настройки, единый пул ресурсов и возможность автоматически согласо-
вывать свои планы с другими проектами. Менеджерам портфеля проек-
тов предоставляется инструмент для эффективного управления ресур-
сами предприятия.
Microsoft Office Project Web Access. — это технология, предостав-
ляющий пользователям доступ к данным по проектам и ресурсам, хра-
нящимся на сервере Project Server. Члены проектных групп, руководи-
тели предприятия и управляющие ресурсами (то есть все, кому необхо-
дим доступ к Project Server, но не требуются средства планирования
Project Профессиональный выпуск 2003) пользуются компонентом Pro-
ject Web Access через веб-обозреватель для просмотра и обновления
данных. Пользователям Project Web Access необходима клиентская ли-
цензия Project Server 2003, клиентская лицензия Microsoft SQL Server™,
а также (при использовании Microsoft Windows® SharePoint™ Services)
клиентская лицензия Microsoft Windows Server™ 2003.
Microsoft Office Project Server 2003 обеспечивает поддержку функ-
ций управления корпоративными проктами и ресурсами, а также воз-
можности совместной работы в рамках решения для корпоративного
управления проектами. Пользователи подключаются к серверу Project
Server 2003 через Project Профессиональный выпуск 2003 или Project
Web Access для получения данных и обновления проектных данных.
62
Для реализации всех возможностей управления корпоративными
проектами и ресурсами требуется использовать SQL Server 2000 в каче-
стве сервера базы данных Project Server 2003.
В качестве операционной системы для Project Server 2003 требует-
ся Windows 2000 Server (или более поздняя версия). Для доступа к воз-
можностям Windows SharePoint Services, таким как управление версия-
ми, извлечение и возврат документов, требуется использовать Project
Server 2003 с операционной системой Windows Server 2003. Сервер Pro-
ject Server 2003 интегрируется со службами Windows SharePoint Services
для обеспечения функций управления документами, решения вопросов,
связанных с проектами, и управления рисками. Windows SharePoint Ser-
vices — это компонент Windows Server 2003, с помощью которого поль-
зователи могут создавать веб-узлы для общего доступа к данным и со-
вместной работы над документами.
Все продукты линейки Microsoft Office Project 2003 полностью ру-
сифицированы.
Spider Project
На рынке программных средств управления проектами в России
наряду с известными зарубежными пакетами присутствует и Россий-
ский пакет Spider Project. В России этот пакет достаточно популярен и
используется крупнейшими корпорациями для управления самыми раз-
нообразными проектами. У пакета Spider Project много отличий от сво-
их зарубежных аналогов, которые делают его привлекательным для
Российских потребителей. Это, прежде всего, связано с принятой в Рос-
сии технологией управления проектами, которая отличается от той, ко-
торая лежит в основе зарубежных пакетов. Так, например, в России
практически во всех областях приложения управления проектами пла-
нируются физические объемы работ, а длительность рассчитывается ис-
ходя из производительностей назначенных ресурсов, а не является ис-
ходной информацией.
Пакет Spider Project разработан компанией Spider Management
Technologies — одной из ведущих в России консалтинговых компаний
по управлению проектами.
Из основных особенностей этого пакета следует отметить:
• возможность составления расписания проекта, основываясь на фи-
зических объемах работ и производительности ресурсов;
• оптимизация использования ресурсов проекта и широкие возмож-
ности моделирования их работы;
• включение в модель проекта поставок и финансирования и расчет
расписания с их учетом;
63
 • расчет и использование ресурсного критического пути и ресурс-
ных резервов;
• интенсивное использование в проектах всевозможных баз данных;
• использование множественных иерархических структур работ и
ресурсов проекта;
• оригинальные подходы к моделированию рисков;
• дополнительные формы графических отчетов.
Главным недостатком, сдерживающим продвижение Spider Project
на рынке программных продуктов управления проектами, является от-
сутствие возможности территориально разнесенного управления корпо-
ративными проектами.
Welcom
Компания Welcom основана в 1983 году. Головной офис корпора-
ции расположен в Хьюстоне, США. Офисы компании находятся в Лон-
доне и Сингапуре. Партнеры - более чем в 20 странах мира. Ее первый
продукт Open Plan вышел в свет в 1985 году. В настоящее время выпус-
кается линейка, состоящая из пяти продуктов: Open Plan, Cobra, Wel-
comHome, WelcomPortfolio, WelcomRisk.
Open Plan — календарное планирование и контроль исполнения
— инструмент разработки, оптимизации и контроля календарных пла-
нов проекта. Система обеспечивает решение следующих задач:
1. Формирование модели проекта: визуализация комплекса работ
без ограничения количества задач (работ) и уровней иерархиче-
ской структуры; все типы связей между работами с учетом ка-
лендарей работы, ресурса и связи; неограниченное число про-
ектов в мультипроекте (программе).
2. Ресурсное планирование позволяет осуществлять оптимизацию
графика работ проекта с учетом наличия ресурсов и позволяет
использование: иерархической структуры ресурсов; всех типов
ресурсов (материальных, людских, финансовых, субконтракт-
ных, с ограниченным сроком годности, пулов ресурсов с уче-
том доступности, квалификации и стоимости каждого ресурса;
двух методов ресурсного планирования (с ограниченными ре-
сурсами и с ограниченным временем); планирования с учетом
альтернативных ресурсов для замены.
3. Мультипроектное планирование позволяет интегрировать неза-
висимые проекты в единый мультипроект, предоставляя ме-
неджеру проекта возможность анализа и ресурсного планиро-
вания на уровне мультипроекта с учетом приоритетности про-
ектов, резервирования ресурсов под конкретные проекты с уче-
64
том их приоритетности в рамках портфеля проектов, получения
консолидированной отчетности по всем проектам.
Cobra — управление бюджетом программ и проектов реализует
следующие функции:
1. Управление бюджетом проекта: разработка, оптимизация и
контроль исполнения бюджета; планирование расходов проекта
на уровне статей затрат; интеграция с системой календарного
планирования.
2. Анализ на основании освоенного объема позволяет провести
сравнение трех основных показателей проекта: плановой стои-
мости выполненных работ; фактической стоимости выполнен-
ных работ; плановой стоимости запланированных работ; вы-
числять параметры отклонения от плановых показателей.
3. Прогнозирование определяет: оптимистическую, пессимисти-
ческую и наиболее вероятностную стоимости работ проекта;
прогнозные значения, сформированные автоматически на осно-
ве расписания проекта; различные варианты статистических
прогнозов с целью выбора наилучшего и вычисление показате-
лей эффективности по каждому варианту.
WelcomHome — обеспечение совместной работы над территори-
ально-распределенным проектом и создания виртуального офиса проек-
та. Он обеспечивает централизованное хранение информации проектов
и доступ к данным с использованием единого Web-интерфейса и реали-
зует следующие функции:
1. Интеграция с системами календарного планирования. Участник
проекта получает возможность: получить информацию о ходе
проекта (состав работ, календарные сроки, назначение ресур-
сов, стоимостные параметры); ввести прогресс выполнения ра-
бот и изменить календарный план; получать задания менеджера
проекта по электронной почте и отчитываться о выполнении;
участвовать в обсуждении проблем в форумах различного со-
держания.
2. Управление документами проекта обеспечивает: иерархиче-
скую структуру и разграничение доступа к папкам документов;
механизм блокировки документов для монопольного редакти-
рования; контроль версий документов.
3. Система безопасности реализует администрирование и разгра-
ничение доступа на уровне пользователей, групп пользовате-
лей, ролей пользователя.
WelcomPortfolio — управление портфелем проектов реализует
функции: выбора первоочередных проектов компании; отслеживание
65
развития первоочередных проектов компании; установление приорите-
тов проектам компании; планирование объемов.
WelcomRisk — управление рисками позволяет осуществлять: на-
стройку категорий для различных типов рисков; использовать и форми-
ровать шаблоны мер реагирования; добавление и настройку шаблонов;
вводить определяемые пользователем вероятности и воздействия, чис-
ленные и субъективные; определять области допустимых рисков.
4.1.3. Обзор программных модулей Primavera
Primavera Systems, Inc. — мировой лидер по разработке программ-
ного обеспечения для управления портфелями проектов, программами,
проектами и ресурсами. Разработан большой спектр программного
обеспечения для процессов управления проектами, который включает:
Primavera Project Planner Professional (P4); MyPrimavera; Primavera Con-
tractor; PMSystems for Construction; PMExchange; Primavera Expedition;
Типовое решение по ведению договоров; Primavera Charts и Primavera
Chart Design; Primavera Project Planner (P3); PrimeContract; SureTrak Pro-
ject Manager; Webster for Primavera; MonteCarlo™ for Primavera; Ra;
Primaplan Project Investigator; Primaplan Flint; A0; PMAgent; Linea Time
Chainage Diagram и др.
Основные программные продукты: Primavera Project Planner Pro-
fessional (P4), MyPrimavera, Primavera Expedition, Primavera Contractor,
Primavera Project Planner(P3) и SureTrak. Primavera Inc признана лидером
в управлении портфелями проектов (Gartner, Inc) и является единствен-
ной в мире компанией, которой это удается последние пять лет.
Решение компании Primavera Systems, Inc ориентировано на соз-
дание единой корпоративной системы управления проектами. Данное
программное обеспечение разработано с учетом отраслевых стандартов
управления и может быть адаптировано в соответствии со специфиче-
скими потребностями каждой конкретной организации.
Применение ПО Primavera позволяет:
• всем уровням управления проектами компании единовременно
пользоваться одной и той же информацией с необходимой степе-
нью агрегации с учетом прав доступа каждого пользователя;
• координировать работу всех участников проектов (проектировщи-
ков, поставщиков, строителей, монтажников, наладчиков и т.д.);
• автоматически рассчитывать критический путь, определять за-
грузку ресурсов и помогать устранять ресурсные конфликты как
внутри одного проекта, так и с учетом всех проектов, ведущихся
компанией;
• сокращать время, затрачиваемое на планирование и перепланиро-
вание, в том числе благодаря использованию базы знаний компа-
66
нии, в которой сохраняются ранее выполненные типовые проекты
и фрагменты проектов. На основании них ИСУП позволяет прово-
дить планирование новых проектов, набирая состав работ из гото-
вых «блоков». Подобная методика не только сокращает время, за-
трачиваемое на планирование, но и уменьшает количество ошибок
планирования;
• автоматизированно вводить фактические данные в графики работ
проекта, что дает возможность оценивать реальное состояние дел
на площадке и сравнивать его с отчетностью подрядчиков (напри-
мер, актами выполненных работ, формами КС-2, КС-3);
• прогнозировать развитие проектов, проводить анализ «Что-Если»
и выбирать вариант проекта, наиболее соответствующий целям
компании.
Ядром системы, выполняющим основные функции служат клиент-
серверные приложения Primavera Enterprise и Primavera Expedition. Эти
приложения работают с СУБД Oracle, MS SQL Server, Sybase.
Основным продуктом в составе Primavera Enterprise является
Primavera Project Management (Primavera Project Planner Professoinal,
P4) — средство календарно-сетевого планирования работ, составления
бюджета, управления сроками, укрупненного анализа и контроля хода
выполнения и координация работ одного, нескольких или всех проектов
организации. Поддерживается организация проектов в портфели, ситуа-
ционное моделирование «Что-Если», управление рисками и показате-
лями и т. д.
Primavera Expedition — продукт, функционал которого связан с
контролем договорных обязательств в ходе выполнения проекта, согла-
сования рабочей документации и ее изменений, учет всей входящей и
выходящей корреспонденции, учет изменений в контрактах, всесторон-
ний контроль за проектной информацией.
В случаях, когда полное обеспечение функциональности продук-
тов не требуется, используются web-приложения, имеющие некоторую
специализацию — myPrimavera, PrimeContract, Progress Reporter,
Webster for Primavera.
Программный продукт MyPrimavera, построенный на современ-
ных web-технологиях, обладает всеми необходимыми возможностями
для контроля и анализа данных по портфелям проектов, разработке и
актуализации графиков, отслеживанию процессов инициации и измене-
ния проектов, управлению документооборотом.
Primavera Contractor — решение для строительного комплекса.
Primavera Contractor — простой в использовании и доступный по сред-
ствам программный продукт для создания графиков строительных про-
ектов. Он разработан на базе стандартного для строительной отрасли
67
программного обеспечения Primavera Project Planner Professional. Благо-
даря Primavera Contractor подрядчики получили возможность участво-
вать в планировании и контроле своих проектов или частей крупного
проекта, а заказчики — возможность обмениваться с подрядчиками
данными в едином формате.
Progress Reporter — web-приложение, которое позволяет выдать
исполнителям задание на период времени и получить отчет об их вы-
полнении. Progress Reporter может использоваться как табель учета ра-
бочего времени.
PrimeContract — интернет-ориентированное программное реше-
ние, позволяющее различным участникам проекта оперативно обмени-
ваться информацией, используя единую базу данных. PrimeContract по-
зволяет создавать и отслеживать схемы жизненного цикла документа,
размещать в Сети чертежи и макеты календарных графиков, а также
вводить информацию о выполнении работ по договорам, передавая её в
систему сопровождения договоров Primavera Expedition.
Webster for Primavera обеспечивает доступ к проектной информа-
ции используя Интернет. Может работать как с Р3, Р4, так и c SureTrak.
SureTrak Project Manager® — SureTrak ориентирован на контроль
выполнения небольших проектов или/и фрагментов крупных проектов.
Функционирует как самостоятельно, так и совместно с Р3 в корпора-
тивной системе управления проектами.
MonteCarlo™ for P3e® — программный продукт, расширяющий
возможности Р3 по управлению рисками.
Primaplan Project Investigator — программный продукт, позво-
ляющий сравнивать две версии проекта или группы проектов, просмат-
ривая при этом все поля данных, существующих в проекте, и при необ-
ходимости объединять отдельные данные в единый проект.
Модули Primavera Charts и Primavera Chart Design расширяют
графические возможности программных продуктов Р4 (Primavera Project
Planner Professional), Primavera Expedition и Primavera Cost Management.
Пользователи могут создавать и редактировать более 90 различных ва-
риантов графиков, используя большой выбор шаблонов диаграмм, гис-
тограмм, круговых и пузырьковых диаграмм.
Primavera Cost Manager — эффективное решение задач управле-
ния стоимостью и анализа по методике освоенного объема в управлении
проектами/портфелями проектов. Новый модуль Cost Manager обладает
расширенными возможностями по управлению стоимостью и освоен-
ным объемом, таким образом, он дополняет Primavera Project Planner
Professional и Primavera Information Technology (Primavera TeamPlay®).
Использование Cost Manager позволит более эффективно управлять
стоимостью проектов, освоенным объемом, анализировать бюджеты,
68
фактическую стоимость и прогнозные оценки по проектам, группам
проектов и портфелям.
Primavera Integration API — Информационная система управления
проектами (ИСУП) является ядром Корпоративной информационной
системы (КИС) проектно-ориентированной компании. Поэтому многие
компании решают задачи интеграции ИСУП со смежными системами,
такими как ERP/MRP, EAM, CAD/CAM, PDM/PLM, GIS, CRM и други-
ми. Для интеграции Primavera со сторонними приложениями предназна-
чен программный модуль Primavera Integration API. Этот модуль разра-
ботан с использованием современных java-технологий, полностью под-
держивает бизнес-логику Primavera и позволяет обеспечивать доступ к
любым ее данным с учетом прав доступа. Обмен данными с другими
приложениями производится с помощью формата XML.
Функциональность продуктов Primavera существенно расширяют
модули и программные комплексы сторонних организаций. Наиболее
распространенными являются продукты компании PMSystem и Инфо-
строй.
PMControlling — программное обеспечение, предназначенное для
расширения функциональности P4. Основные функциональные воз-
можности модуля: контроль выполнения планов капитальных вложе-
ний; подготовка титульных списков объектов строительства, подготов-
ка, согласование и заключение договоров; управление проектно-
изыскательскими работами на объектах; контроль исполнения обяза-
тельств по договорам.
PMLogistics — программное обеспечение, предназначенное для
расширения функциональности P4. Основные функциональные воз-
можности: управление материально-техническим обеспечением строи-
тельства, маркетинг и договорное обеспечение поставок, ведение еди-
ного каталога материально-технических ресурсов, складская логистика,
контроль поставок материально-технических ресурсов.
PMFinance — программное обеспечение, предназначенное для
расширения функциональности P4. Модуль для управления финансиро-
ванием капитального строительства: подготовкой планов финансирова-
ния капитального строительства, планированием первоочередных пла-
тежей; контролем взаиморасчетов с поставщиками, подрядчиками, про-
ектными организациями; контролем исполнения планов финансирова-
ния капитального строительства.
PMExchange — решение предназначено для удаленной работы с
пакетом P4. Приложение PMExchange направлено на обеспечение опе-
ративного и эффективного взаимодействия между руководством проек-
та и исполнителями. PMExchange — это простое в использовании реше-
ние, направленное на облегчение процессов сбора информации о факти-
69
ческом выполнении работ проекта и проведения детального планирова-
ния.
Сметно-аналитический комплекс А0 компании Инфострой для
выпуска сметной документации, подготовки и учета строительного
производства, предназначен для использования всеми участниками ин-
вестиционного процесса. Может использоваться в составе корпоратив-
ной информационной системы, включает подсистему разграничения
доступа. Содержит модуль для выпуска смет на проектно-
изыскательские работы и модуль экспорта сметных данных в систему
управления проектами SureTrak и P3.
PMAgent — программный продукт, позволяющий устанавливать и
поддерживать в актуальном состоянии связи между работами в
Primavera Project Planner Professional (P4) и строками локальных смет в
А0. PMAgent передает в работы графика трудозатраты, машины, мате-
риалы, оборудование и стоимостные показатели, а также позволяет рас-
пределить физические объемы по нескольким работам графика.
Система управления проектами на базе Primavera является гибкой
информационной системой. Сочетая работу в единой базе данных раз-
личных приложений с единой идеологией разграничения прав пользова-
телей, система оптимально распределяет функции между участниками
проекта. Увеличение масштабов системы не нарушает ее целостности и
надежности, затрагивая только аппаратуру серверной компоненты, а
применение web-ориентированных приложений упрощает состав про-
грамм на клиентском месте, минимизирует затраты на эксплуатацию
системы.
При ведении большого количества проектов в организации про-
дукты Primavera предоставляют богатый и гибкий инструментарий по
формированию любой сводной информации, группируя данные по
множеству критериев. Система определяет приоритеты задач, контро-
лирует графики, фиксирует отклонения и уведомляет ответственных.
Основной «интеллектуальной» силой Primavera выступает многовари-
антный анализ, возможность с использованием глобальной замены пе-
ренастраивать весь проект, возможность создавать любые отчетные
формы по любым выборкам. Кроме того, наличие модуля Primavera Ex-
pedition Express, работающего на платформе Palm (наладонный компь-
ютер) позволяет в удаленном режиме вводить информацию о текущем
положении дел в проекте.
Особенную функцию несет модуль Primavera Architect — база
знаний по управлению проектами, хранилище типовых фрагментов гра-
фиков, собственных наработок и отраслевых стандартов, называемых
методологиями, создаваемых с использованием Primavera Methodology
Manager.
70
4.2. Обеспечивающие подсистемы информационных
систем управления проектами
Обеспечивающие подсистемы являются общими для всей ИСУП
независимо от конкретных функциональных подсистем, в которых при-
меняются те или иные виды обеспечений. Состав обеспечивающих под-
систем не зависит от выбранной предметной области и включает: функ-
циональную структуру, информационное, математическое (алгоритми-
ческое и программное), техническое, организационное, кадровое, а на
стадии разработки ИСУП дополнительно — правовое, лингвистическое,
технологическое и методологическое обеспечения, а также интерфейсы
с внешними ИС.
В целом работу ИСУП в контуре управления определяют ее функ-
циональная структура и информационное обеспечение; поведение чело-
века — организационное и кадровое; функции автомата — математиче-
ское и техническое обеспечения.
Функциональная структура представляет собой перечень реали-
зуемых ею функций (задач) и отражает их соподчиненность. Под функ-
цией понимается круг действий ИСУП, направленных на достижение
частной цели управления. Состав функций, реализуемых в ИСУП, рег-
ламентируется ГОСТом и подразделяется на информационные и управ-
ляющие функции.
Информационные, в свою очередь, включают в себя функции:
централизованного контроля (1 — измерение значений параметров, 2 —
измерение их отклонений от заданных значений) и вычислительных и
логических операций (3 — тестирование работоспособности ИС и 4 —
подготовка и обмен информацией с другими системами).
Управляющие включают функции: 5 — поиска и расчета рацио-
нальных режимов управления, 6 — реализации заданных режимов
управления.
Информационное обеспечение — это совокупность средств и ме-
тодов построения информационной базы. Оно определяет способы и
формы отображения состояния объекта управления в виде данных внут-
ри ИСУП, документов, графиков и сигналов вне ИСУП. Информацион-
ное обеспечение подразделяют на внешнее и внутреннее.
Математическое обеспечение состоит из алгоритмического и
программного. Алгоритмическое обеспечение представляет собой сово-
купность математических методов, моделей и алгоритмов, используе-
мых в системе для решения задач и обработки информации. Программ-
ное обеспечение состоит из общего (ОС, трансляторы, тесты и диагно-
стика и др., т.е. все то, что обеспечивает работу «железа») и специаль-
71
ного (прикладное программное обеспечение, обеспечивающее автома-
тизацию процессов управления в заданной предметной области).
Техническое обеспечение состоит из устройств: измерения, преоб-
разования, передачи, хранения, обработки, отображения, регистрации,
ввода/вывода информации и исполнительных устройств.
Кадровое обеспечение — это совокупность методов и средств по
организации и проведению обучения персонала приемам работы с ИС.
Его целью является поддержание работоспособности ИС и возможности
дальнейшего ее развития. Кадровое обеспечение включает в себя мето-
дики обучения, программы курсов и практических занятий, технические
средства обучения и правила работы с ними и т.д.
Организационное обеспечение — это совокупность средств и ме-
тодов организации производства и управления им в условиях внедрения
ИСУП. Целью организационного обеспечения является: выбор и поста-
новка задач управления, анализ системы управления и путей ее совер-
шенствования, разработка решений по организации взаимодействия
ИСУП и персонала, внедрение задач управления. Организационное
обеспечение включает в себя методики проведения работ, требования к
оформлению документов, должностные инструкции и т.д.
Это обеспечение является одной из важнейших подсистем ИСУП,
от которой зависит успешная реализация целей и функций системы. В
его состав входит четыре группы компонентов.
Первая группа включает в себя важнейшие методические материа-
лы, регламентирующие процесс создания и функционирования системы
(общеотраслевые руководящие методические материалы по созданию
ИС, типовые проектные решения, методические материалы по органи-
зации и проведению предпроектного обследования на предприятиях;
методические материалы по вопросам создания и внедрения проектной
документации).
Ко второй группе относят совокупность средств, необходимых для
эффективного проектирования и функционирования ИС (комплексы за-
дач управления, включая типовые пакеты прикладных программ; типо-
вые структуры управления предприятием; унифицированные системы
документов; общесистемные и отраслевые классификаторы и т.п.).
В третью группу входит техническая документация, получаемая в
процессе обследования, проектирования и внедрения системы (технико-
экономическое обоснование; техническое задание; технический и рабо-
чий проекты и документы, оформляющие поэтапную сдачу системы в
эксплуатацию).
К четвертой группе относится подсистема, в которой представлено
организационно-штатное расписание, определяющее, в частности, со-
став специалистов по функциональным подсистемам управления.
72
Правовое обеспечение предназначено для регламентации процесса
создания и эксплуатации ИСУП, которое включает в себя совокупность
юридических документов с констатацией регламентных отношений по
формированию, хранению, обработке промежуточной и результирую-
щей информации системы.
Лингвистическое обеспечение (ЛО) представляет собой совокуп-
ность научно-технических терминов и других языковых средств, ис-
пользуемых в информационных системах, а также правил формализа-
ции естественного языка, включающих в себя методы сжатия и раскры-
тия текстовой информации для повышения эффективности автоматизи-
рованной обработки информации. Средства, входящие в подсистему
ЛО, делятся на две группы: традиционные языки (естественные, мате-
матические, алгоритмические, языки моделирования) и предназначен-
ные для диалога с ЭВМ (информационно-поисковые, языки СУБД, опе-
рационных сред, входные языки пакетов прикладных программ).
Технологическое обеспечение (Electronic Data Processing — EDP)
соответствует разделению ИСУП на подсистемы по технологическим
этапам обработки различных видов информации:
• первичной информации (этапы технологического процесса сбора,
передачи, накопления, хранения, обработки первичной информа-
ции, получения и выдачи результатной информации);
• организационно-распорядительной документации (этапы получения
входящей документации, передачи на исполнение, этапы формиро-
вания и хранения дел, составления и размножения внутренних до-
кументов и отчетов);
• технологической документации и чертежей (этапы ввода в систему
и актуализации шаблонов изделий, ввода исходных данных и фор-
мирования проектной документации для новых видов изделий, вы-
дачи на плоттер чертежей, актуализации банка ГОСТов, ОСТов,
технических условий, нормативных данных, подготовки и выдачи
технологической документации по новым видам изделий);
• баз данных и знаний (этапы формирования баз данных и знаний,
ввода и обработки запросов на поиск решения, выдачи варианта
решения и объяснения к нему);
• научно-технической информации, ГОСТов и технических условий,
правовых документов и дел (этапы формирования поисковых обра-
зов документов, формирования информационного фонда, ведения
тезауруса справочника ключевых слов и их кодов, кодирования за-
проса на поиск, выполнения поиска и выдачи документа или адреса
хранения документа).
73
 Интерфейсы с внешними ИС (Interfaces) обеспечивают обмен дан- • внешние пользователи (External Users) — потребители выходной
ными, расширение функциональности приложений за счет программно- информации ИС, контрагенты.
го интерфейса Application Program Interface, API и доступа к:
• объектам Microsoft Jet (БД, электронные таблицы, запросы, наборы 4.3. Жизненный цикл информационной системы
записей и др.) в программах на языках Microsoft Access Basic, управления проектами.
Microsoft Visual Basic — DAO (Data Access Object); Процесс создания информационной системы описывается с помо-
• реляционным БД под управлением WOSA (Microsoft Windows Open щью следующей иерархии понятий: Жизненный цикл, Фазы, Стадии,
Standards Architecture) — ODBC (Open Database Connectivity); Этапы, Работы, Процессы, Операции, Элементы. Процесс создания ин-
• компонентной модели объектов — COM (Component Object Model), формационной системы управления проектами реализует функции
поддерживающей стандартный интерфейс доступа к объектам и ме- управления на протяжении всего жизненного цикла ИС, который вклю-
тодам обработки объектов независимо от их природы, местонахож- чает следующие фазы: “зарождение”, “разработка”, “эксплуатация”,
дения, структуры, языков программирования; “демонтаж” (рис.4.3-1).
• локальным и удаленным объектам других приложений на основе
технологии манипулирования Automation (OLE Automation), обес-
печивающей взаимодействие сервера и клиента;
• объектам ActiveX (элементам управления OLE и OCX) для их
включения в веб-приложения при сохранении сложного формати-
рования и анимации и др.
ИСУП поддерживает работу следующих категорий пользователей:
• конечные пользователи (End Users, Internal Users) — управленче-
ский персонал, специалисты, технический персонал, которые по
роду своей деятельности используют информационные технологии
управления;
• администрация ИС, в том числе:
— конструктор или системный аналитик (Analyst) — обеспечивает
управление эффективностью ИС, определяет перспективы развития
ИС;
— администратор приложений (Application Administrator) — отве-
чает за формализацию информационных потребностей бизнес-
приложений, управление эффективностью и развитием бизнес-
приложений;
— администратор данных (Data Base Administrator) — осуществля-
ет эксплуатацию и поддержание качественных характеристик ИБ (БД);
— администратор компьютерной сети (Network Administrator) —
обеспечивает надежную работу сети, управляет санкционированным
доступом пользователей, устанавливает защиту сетевых ресурсов;
• системные и прикладные программисты (System Programmers,
Application Programmers) — осуществляют создание, сопровожде-
ние и модернизацию программного обеспечения ИС;
• технический персонал (Technicians) — обеспечивает обслуживание
технических средств обработки данных;

74 75
 Важнейшими фазами жизненного цикла ИСУП являются фазы
“зарождение” и “разработка”, которые состоят из следующих семи ста-
дий: «формирование требований» и «разработка концепции»; «техниче-
ское задание» (ТЗ); «технический проект» (ТП); «внедрение» (Вн).
Методология создания ИСУП отражена в нормативных докумен-
тах, подавляющее большинство которых имеют силу международных
стандартов. В них определены терминология, порядок создания и вне-
дрения, требования к частям, состав проектов.
Последовательность работ, связанных с определением целесооб-
разности создания, созданием и промышленной эксплуатацией инфор-
мационных систем (ИС), оформлена в виде процесса (создания или из-
готовления), который имеет иерархическое описание и состоит из ста-
дий. Каждая стадия состоит из этапов, а этапы, в свою очередь, состоят
из видов работ.
Рассмотрим подробнее содержание процесса создания и внедрения
ИСУП, который включает следующие стадии, этапы и некоторые виды
работ.
СТАДИИ 1.1. «Формирование требований» и 1.2. «Разработка
концепции». Основная цель этапов и работ этих стадий состоит в фор-
мировании обоснованного с позиций заказчика предложения о создании
ИСУП с определенными основными функциями и техническими харак-
теристиками. Основными выходными документами этой стадии явля-
ются: отчеты и технико-экономическое обоснование целесообразности
создания ИСУП с выбранными функциями и их характеристиками; за-
явка на создание ИСУП и исходные технические требования к ИСУП в
объеме, соответствующем ГОСТ.
СТАДИИ 2.1. «Техническое задание» (ТЗ) и 2.2. «Эскизное проек-
тирование». Основными целями стадии являются: подтверждение целе-
сообразности и детальное обследование возможности создания эффек-
тивной ИСУП с функциями и техническими характеристиками, сфор-
мулированными в виде исходных технических требований к системе;
планирование совокупности всех НИР, ОКР, проектных и монтажно-
наладочных работ, сроков их выполнения и организаций исполнителей;
подготовка всех материалов, необходимых для проведения проектных
работ. Выходными документами стадии являются: ТЗ на создание
ИСУП, содержащее технические требования и план-график работ, со-
гласованные Заказчиком и Основным исполнителем; уточненное техни-
ко-экономическое обоснование намеченных в ТЗ решений (при необхо-
димости); научно-технический отчет, содержащий результаты прове-
денных предпроектных исследований; эскизный проект ИСУП.
СТАДИЯ 2.3. «Технический проект» (ТП). Целями работ, выпол-
Рис.4.3-1. Жизненный цикл ИСУП няемых на этой стадии, являются разработка основных технических ре-
76 77
шений по создаваемой системе и окончательное определение ее сметной
стоимости. Работы этой стадии завершаются разработкой: общесистем-
ных решений, необходимых и достаточных для выпуска эксплуатаци-
онной документации на систему в целом; проектно-сметной документа-
ции, входящей в состав раздела «Автоматизация» технического проекта
строительства; проектов заявок на разработку новых технических
средств; документации специального математического и технического
обеспечений, включая техническое задание на программирование. Ос-
новные результаты работ стадии оформляются в виде технического
проекта ИСУП.
СТАДИЯ 2.4. «Рабочая документация». Целью работ, выполняе-
мых на этой стадии, является выпуск рабочей документации на созда-
ваемую систему. Работы этой стадии завершаются выпуском рабочего
проекта ИСУП, состоящего из проектной документации, необходимой и
достаточной для приобретения, монтажа и наладки комплекса техниче-
ских средств системы, и документации программного и организацион-
ного обеспечений, необходимых и достаточных для наладки и эксплуа-
тации системы, и изготовлением программ специального программного
обеспечения на машинных носителях.
СТАДИЯ 2.5. «Внедрение» (Вн). Цель стадии и главный результат
работ, выполняемых здесь, передача действующей системы в промыш-
ленную эксплуатацию, а также получение объективных и систематизи-
рованных данных о качестве созданной системы, текущем состоянии и
реальном эффекте функционирования системы на основании опыта ее
промышленной эксплуатации. Анализ функционирования выполняется
также и в ходе промышленной эксплуатации. С этой целью определя-
ются показатели эксплуатационной надежности для системы в целом и
отдельных реализуемых ею функций, показатели технико-экономи-
ческой эффективности системы, функционально-алгоритмическая пол-
нота (развитость) системы и социально-психологическая подготовка
персонала системы.

78

5. Архитектура информационной системы управления
проектами, построенной на базе Primavera
5.1. Методология концентрического управления
проектами
Увеличение количества компаний, деятельность которых связана с
управлением одновременно многими проектами, привело к развитию
новых методов и моделей проектного управления и совершенствованию
программных продуктов, реализующих эти разработки.
В каждой компании существуют определенные, иногда значитель-
ные, особенности управления проектами. Эти различия в рамках систе-
мы управления проектами отражаются на уровне формирования кон-
кретных управленческих процедур, схем согласования документов и
т. д. Концепция интегрированной СУП может быть представлена рядом
основных вариантов решений, которые составляют основу общей для
самых разных предприятий методики внедрения и использования сис-
темы управления проектами конкретного предприятия.
Использование интегрированной системы управления проектами
предприятия подразумевает не только совместное использование инст-
рументальных средств, но и особые формы и технологии управления,
позволяющие вписать управление проектами в общую сферу деятельно-
сти компании.
В современной компании управлять надо именно проектами, а не
процессами или функциями8. Сотни, а иногда и тысячи разных по объе-
му и продолжительности проектов нацелены на то, чтобы улучшить ка-
чество, снизить затраты, увеличить мощность, сократить время изготов-
ления изделий, вывести новую продукцию на рынок — и все это ради
достижения конкурентных преимуществ компании.
Традиционная система управления проектами хорошо подходила
для однородных, независимых друг от друга крупных проектов. Для их
выполнения создавалась команда по проекту, которая работала под ру-
ководством управляющего проектом, занятого по этому проекту полный
рабочий день. Члены команды никак не участвовали в другой деятель-
ности корпорации.
Особенностью современного этапа является переориентация ком-
паний выполнение многочисленных проектов различного масштаба.
Персонал из разных подразделений выполняет задачи по проекту, и это
занимает не более 5-10% от их недельной загрузки. Руководят проекта-
8
http://pmsoft.ru/doc/THEORY/PUB/CORPPM.ASP. А. Цветков, Е. Колосова. Корпоративный подход к
управлению проектами с использованием продуктов Primavera.
79
ми менеджеры из разных подразделений. Работа по проекту выполняет-
ся там, где присутствуют необходимые ресурсы.
Для управления компанией в изменившихся условиях нужна новая
модель управления проектами, предусматривающая одновременную ко-
ординацию и консолидацию данных, подчинение всех проектов общим
целям компании при сохранении независимого управления отдельными
проектами.
Компания Primavera Systems Inc. предложила новую методологию
для управления проектами — концентрическое управление проектами
Concentric Project Management или СРМ. Концентрическое управление
проектами является логическим развитием методологии управления
проектами на современном этапе.
По сравнению с традиционной методологией управления проекта-
ми СРМ обеспечивает четыре важных преимущества9:
• Визуализация данных. Каждый проект становится важным, а его
результаты прозрачными для компании, все участники видят
реальное состояние дел. Возрастает роль расписаний, команда
проекта регулярно подводит итоги, чтобы знать, как изменить
оставшуюся часть проекта, перераспределить ресурсы.
• Координация. Команда проекта понимает, что главная задача —
сообща следовать стратегическим курсом компании. Если кто-
либо отклоняется от общего направления, это немедленно вы-
является, и принимаются эффективные меры. СРМ инициирует
ведение диалога внутри компании.
• Усиление. Когда люди знают, что их работа является частью
выполнения общей стратегической задачи, что их труд виден,
возрастает отдача от каждого работника.
• Конкурентные преимущества. Улучшается процесс принятия
решений, так как с помощью СРМ компромиссы становятся
прозрачными. СРМ предоставляет специальные средства для
анализа чувствительности и поддержки принятия решений, ко-
торые помогают выбрать наиболее конкурентоспособный про-
ект, обеспечивающий наибольшую прибыль на инвестирован-
ный капитал.
СРМ — структурированный, интегрированный и масштабируемый
подход к координации людей, команд и проектов.
Структурированный. Структура — приобретает особенное значе-
ние, когда возрастает размер и сложность проектов или увеличивается
их количество. Система управления проектами предполагает, что все
проекты имеют одинаковую структуру и подчиняются общим правилам,
9
Колосова Е.В., Цветков А.В. Концентрическое управление проектами// "Readme". - 1999. - №2.
80

6. Ведение проекта в Primavera
6.1. Фаза «Инициация»
На этой фазе определяется проект, проводится анализ осуществи-
мости проекта. Работы этой фазы включают мероприятия по маркетин-
гу, подготовке и участию в тендерах и конкурсах и другие мероприятия
преддоговорной работы. На фазе инициации проекта ведется концепту-
альное планирование будущего проекта и планируется работа времен-
ной рабочей группы проекта (ВРГП). Особенностью управления проек-
том на фазе инициации является обычно большая длительность (неоп-
ределенные сроки завершения фазы). Также существенна вероятность
отказа от перехода к последующим фазам жизненного цикла проекта
(выявленная экономическая нецелесообразность, проигрыш тендера и
т.п.).
Чтобы понять необходимость осуществления проекта, необходимо
изучить потенциальных потребителей продукта, созданного в результа-
те реализации проекта, уровень конкуренции на рынке и определить ха-
рактеристики конечного продукта. Именно поэтому начальная фаза
проекта является важнейшей фазой проведения подготовительных ра-
бот. На этой фазе осуществляется обоснование проекта и принимается
решение об его исполнении. Результаты проработки идеи будущего
проекта на этой фазе позволят избежать проблем на всех последующих
фазах жизненного цикла проекта. Особенно стоит отметить важность
предпроектной стадии для инвесторов, поскольку цена изучения вопро-
са об эффективности проекта на этой стадии несоизмеримо ниже воз-
можных убытков в будущем, когда недостаточно проработанный проект
будет уже инициирован.
Недооценка значения фазы инициации является достаточно рас-
пространенной ошибкой. Очень часто в силу определенных условий,
при проведении работ фазы инициации начинают проводиться работы
следующей предполагаемой фазы планирования, а, бывает, и фазы ис-
полнения проекта. PMBOK Guide of knowledge (Свод знаний по управ-
лению проектами) определяет инициацию как процесс формального
санкционирования нового проекта или перехода выполняющегося про-
екта в следующую фазу. Но формальное санкционирование проекта в
большинстве организаций не происходит без предварительного анализа
и планирования. Работу на этой фазе можно рассматривать как отдель-
ный проект, выполняемый своей командой, со своими сроками и бюд-
жетом.
Информационная система управления проектами (ИСУП) реали-
зованная на базе программных продуктов Primavera, обеспечивает вы-
111
полнение задач календарно-сетевого планирования не только на фазах
уже собственно реализации проекта, когда известны и конкретизирова-
ны большинство исходных данных проекта, но и на этапе определения
параметров будущего проекта.
Ниже приведены некоторые приемы и примеры использования ин-
струментов Primavera при моделировании плана работы ВРГП и состав-
лении концептуального плана проекта на фазе инициации.
• При моделировании работы ВРГП, как один из вариантов, про-
ект создается в структуре проектов предприятия (EPS) со стату-
сом «Планируемый». При составлении плана работы ВРГП
для обозначения таких ключевых моментов, как «подписание
приказа…», «проведение совещания…», «подписание пись-
ма…» и т.д., лучше использовать работы типа веха, которые
имеют нулевую длительность. Таким образом, можно смодели-
ровать план работы ВРГП по вехам.
• При создании проекта в структуре проектов предприятия целе-
сообразно в идентификаторе проекта добавлять обозначение
ВРГП (планирование работы ВРГП) или КП (создание концеп-
туального плана проекта), как это представлено на рис. 6.1-1. В
дальнейшем это будет удобным параметром, используемым при
построении отчетов (например, для отображения / скрытия в
отчете данных по обозначенным проектам).
Рис. 6.1-1. Концептуальный план проекта и план работы ВРГП
в структуре проектов предприятия.
• Основной характеристикой фазы инициации с позиции созда-
ния концептуального плана будущего проекта является много-
вариантность. В ИСУП должна существовать возможность
создания нескольких вариантов плана будущего проекта и ин-
струментов для их дальнейшего сравнения между собой по оп-
ределенным параметрам. В Primavera такой возможностью яв-
ляется создание проектов со статусом «Что-если» (рис. 6.1-2).
112
 В диалоговом окне Сортировать нажать кнопку Новый, выпол-
7. Анализ, отображение и печать информации по проекту нить щелчок в ячейке Название поля и из списка выбрать поле, по ко-
торому будет осуществлена сортировка данных. Выполнить щелчок в
7.1. Отображение данных проекта.
ячейке Порядок сортировки и из списка выбрать порядок сортировки
Несмотря на то, что проектные данные для удобства восприятия данных. Нажать кнопку ОК в окне Сортировать, при необходимости
представлены специфическим образом, каждое представление может предварительного просмотра результата сортировки нажать кнопку
содержать слишком большой объем информации. Трудно быстро разо- Применить в диалоговом окне Группировка и сортировка, изменить
браться в задачах на текущую неделю, имея перед собой график проекта критерии сортировки и затем нажать кнопку ОК.
из нескольких сотен уровней WBS и пары-тройки тысяч работ. Поэтому
важно иметь возможность, представлять данные в хорошо восприни-
маемом, преобразованном в соответствии с задачей виде и отбирать
только нужные на данный момент данные.
Для выполнения этих задач используются механизмы сортировки,
группировки и фильтрации данных. Сортировка располагает данные в
удобном виде, группировка сводит однотипные данные вместе, а
фильтрация позволяет отбирать для отображения только нужные дан-
ные.
7.1.1. Сортировка данных
Сортировка используется для определения порядка, в котором бу-
дут отображаться данные. Сортировка данных выполняется на основе
указанных при ее настройке критериев и позволяет представить все
многообразие данных в нужном пользовательском представлении.
Для настройки сортировки выполнить команду меню Вид — 2. Вы- 1. На-
Группировка и сортировка (рис.7.1-1). В диалоговом окне Группи- брать жать
ровка и сортировка нажать кнопку Сортировать:
Рис.7.1-2. Диалоговое окно команды Сортировать.

7.1.2. Фильтрация данных

В отличие от сортировки, фильтрация данных осуществляет выбо-
рочное отображение данных по заданным критериям. Отфильтрованные
(не соответствующие критериям фильтрации) данные не отображаются.
Примером может служить случай, когда требуется отобразить на графи-
ке Гантта только вехи, а остальные работы скрыть.
Категории фильтров:
Нажать • Глобальные — доступны для всех пользователей.
• Встроенные (по умолчанию) — созданные разработчиками,
являются глобальными, доступными для всех пользователей.
Рис.7.1-1. Диалоговое окно команды Группировка и сортировка.
• Пользовательские — созданные пользователем РМ — доступ-
ны изначально только для текущего пользователя. Но в даль-
нейшем могут быть переопределены как глобальные.
171 172
 Раздел 6 — Цикл OPM3
Приложения 6.1 Введение
6.2 Диаграмма Цикла OPM3
Приложение 1
6.3 Шаги Цикла OPM3
Ниже приводится оглавление элемента ЗНАНИЕ модели органи-
зационной зрелости управления проектами. СЕКЦИЯ 4: ПРИЛОЖЕНИЯ
Приложение A: Процесс стандартизации PMI
СЕКЦИЯ 1: ВВЕДЕНИЕ В OPM3 Приложение B: Эволюция Организационной Модели Зрелости Управ-
Раздел 1 — Основные идеи ления Проектами
1.1 Назначение и область применения OPM3 Приложение C: Разработчики и Рецензенты OPM3
1.2 Реализация через проекты корпоративной стратегии компании Приложение D: Самооценка с использованием OPM3
1.3 Корпоративное управление проектами Приложение E: Всесторонняя Оценка: Детальные Шаги
1.4 Организационная зрелость Приложение F: Справочник Лучших Практик
Приложение G: Справочник Возможностей
Раздел 2 —Краткий обзор
Приложение H: Справочник «Планирование Улучшений»
2.1 Как организован Стандарт
Приложение I: Модели процессов Управления Программой и Портфе-
2.2 Знание, Оценка и Улучшение
лем Проектов
2.3 Введение в OPM3

СЕКЦИЯ 2: ПОНИМАНИЕ МОДЕЛИ

Раздел 3 — Лучшие Практики
3.1 Что такое Лучшие Практики?
3.2 Как могут быть использованы Лучшие Практики
3.3 Возможности, Результаты и Ключевые Показатели Эффективности
3.4 Зависимости между Лучшими Практиками и Возможностями
3.5 Категоризация Лучших Практик и Возможностей в OPM3

Раздел 4 — Процессы Корпоративного Управления проектами

4.1 Введение
4.2 Проекты, Программы и Портфели
4.3 Процессы Управления Проектами
4.4 Процессы Управления Программами
4.5 Процессы Управления Портфелем проектов
4.6 Как процессы управления Портфелем проектов, Программой и Про-
ектами составляют Процесс Корпоративного Управления проектами

СЕКЦИЯ 3: ИСПОЛЬЗОВАНИЕ МОДЕЛИ

Раздел 5 — Справочники OPM3
5.1 Введение
5.2 Объяснение Справочников
5.3 Образцы Справочников

226 227
 Приложение 2. Регламент бизнес-процесса – документ, описывающий последо-
Глоссарий процессного подхода к управлению вательность операций, ответственность, порядок взаимодействия ис-
полнителей и порядок принятия решений по улучшениям.
Бизнес-процесс – устойчивая, целенаправленная совокупность Ресурсы – информация (документы, файлы), финансы, материалы,
взаимосвязанных видов деятельности (последовательность работ), кото- персонал, оборудование, инфраструктура, среда, программное обеспе-
рая по определенной технологии преобразует входы в выходы, пред- чение, необходимые для выполнения бизнес-процесса.
ставляющие ценность для потребителя. Модель – графическое, табличное, текстовое, символьное описа-
Владелец бизнес-процесса – должностное лицо, которое имеет в ние бизнес-процесса либо их взаимосвязанная совокупность.
своем распоряжении персонал, инфраструктуру, программное и аппа- Функция – направление деятельности элемента организационной
ратное обеспечение, информацию о бизнес-процессе, управляет ходом структуры, представляющие собой совокупность однородных операций,
бизнес-процесса и несет ответственность за результаты и эффектив- выполняемых на постоянной основе.
ность бизнес-процесса.
Вход бизнес-процесса – ресурс, необходимый для выполнения
бизнес-процесса.
Выход бизнес-процесса – результат (продукт, услуга) выполнения
бизнес-процесса.
Документооборот – система документального обеспечения дея-
тельности предприятия.
Заказчик – должностное лицо, имеющее ресурсы и полномочия
для принятия решения о проведении работ по описанию, регламентации
или аудиту (проверке) бизнес-процесса.
Показатели бизнес-процесса – количественные и/или качествен-
ные параметры, характеризующие бизнес-процесс и его результат.
Показатели эффективности бизнес-процесса (ПЭ) – параметры
бизнес-процесса, характеризующие взаимоотношение между достигну-
тым результатом и использованными ресурсами.
Показатели продукта (услуги)(ПП) – параметры продукта биз-
нес-процесса.
Показатели (данные) удовлетворенности клиента (потребителя)
(ДУК) – параметры удовлетворенности клиента.
Поставщик – субъект, предоставляющий ресурсы.
Потребитель (клиент) – субъект, получающий результат бизнес-
процесса. Потребитель может быть:
а) внутренний – то есть находящийся в организации и, в ходе сво-
ей деятельности, использующий результаты (выходы) предыдущего
бизнес-процесса;
б) внешний – то есть находящийся за пределами организации и ис-
пользующий или потребляющий результат деятельности (выход) орга-
низации.
Операция (работа) – часть бизнес-процесса.

228 229
 Приложение 3.
Глоссарий управления проектами
Базис (Project Baseline) - Основополагающие параметры и фикси-
рующие их согласованное понимание всеми участниками документы
проекта – «точка опоры» для всего последующего развития проекта.
Базис (Project Baseline) - основополагающие параметры и, фик-
сирующие их согласованное понимание всеми участниками, документы
проекта - "точка опоры" для всего последующего развития проекта. -
первоначальный план проекта с утвержденными изменениями. Базовый
план бывает также и по составляющим проекта - стоимости, расписа-
нию и т.д. [ОУП].
Бюджет проекта (Project budget) - Утвержденное запланированное
распределение финансовых средств проекта по различным основаниям:
• по статьям затрат; по временным периодам, по участникам проек-
та; по решаемым задачам, по компонентам ожидаемых результа-
тов; по элементам организационной структуры проекта и т. п.
• сметная стоимость, распределенная по периодам выполнения про-
екта [НТК].
Выражение "if" — Определяет условия, при которых должны
быть выполнены определенные изменения данных проекта. Если усло-
вие "if" выполнено, то Р3е производит изменения, указанные в выраже-
нии "then", если условие "if" не выполнено, то Р3е производит измене-
ния, указанные в выражении "else".
Группировка — Организация данных проекта по общему при-
знаку. В P3e каждая группа работ выделяется цветным заголовком.
Зависимость "Старт к старту" (SS) — Зависимость между ра-
ботами, при которой старт работы— последователя зависит от старта
работы— предшественника.
Зависимость "Старт к финишу" (SF) — Зависимость между ра-
ботами, при которой работа— последователь не может быть завершена
до тех пор, пока не начнется работа— предшественник.
Зависимость "Финиш к старту" (FS) — Зависимость, при кото-
рой работа— последователь начинается после завершения работы—
предшественника. Эта зависимость является зависимостью по умолча-
нию.
Зависимость "Финиш к финишу" (FF) — Зависимость, при ко-
торой работа последователь должна быть закончена к окончанию рабо-
ты предшественника.
Заинтересованные лица (Stakeholders) - физические и юридиче-
ские лица, как непосредственно участвующие в проекте, так и те, чьи
230
интересы могут быть затронуты процессами осуществления проекта и
его результатами.
Иерархическая структура работ — структуризация работ проек-
та, отражающая его основные результаты. Каждый следующий уровень
иерархии отражает более детальное определение компонентов проекта
[ОУП].
Изменения — Увеличение или уменьшение характеристик эле-
ментов проекта. Пересмотр базового плана проекта. Подразумевает до-
кументально оформленные и утвержденные изменения [УП].
Изменения проекта (Project Changes) — модификация ранее со-
гласованных продуктов и услуг, сроков исполнения и стоимости работ,
используемых ресурсов, управленческих и технологических процессов
и т.п.
Календарный план проекта (Project Schedule) — перечень пла-
нируемых работ проекта со сроками исполнения и ответственными ли-
цами, подготовленный в соответствующей форме, определенной планом
управления проектом.
Ключевые вехи проекта (Project Milestones) — ключевые собы-
тия проекта, свершение которых является необходимым и достаточным
условием, определяющим достижение результатов проекта. Обычно
представляются в виде схемы или таблицы с взаимосвязями и сроками
свершения, образуя План по Вехам (Milestone Plan, Milestone
Schedule, Master Schedule).
Контрольное событие — важное событие проекта, обычно свя-
занное с достижением важнейших результатов [ОУП].
Корневой ресурс — Ресурс самого высокого уровня для Вашей
организации. Вы не можете удалять корневой ресурс из иерархии ре-
сурсов. Однако, Вы можете редактировать информацию по корневому
ресурсу.
Корневой элемент — Элемент самого высокого уровня в струк-
туре проектов предприятия (EPS), организационной структуре (OBS)
или структуре декомпозиции работ (WBS).
Критический путь — самая продолжительная последователь-
ность работ проекта, имеющих нулевой или отрицательный резерв.
Длительность работ, лежащих на критическом пути, определяет дли-
тельность проекта в целом; задержка любой из этих работ задержит да-
ту финиша всего проекта.
Куратор проекта (Sponsor) — лицо, отвечающее перед руково-
дством предприятия за успех проекта в целом и имеющее полномочия
для решения ресурсных и других проблем, эскалированых руководите-
лем проекта.
231
 Менеджер проекта — лицо, ответственное за управление проек-
том [PMBOK].
Метод критического пути (МКП) — Метод, использующий
длительности работ и зависимости между ними, для расчета расписания
проекта в целом. МКП фокусирует внимание на критическом пути,
влияющем на дату завершения проекта в целом или на его промежуточ-
ные этапы.P3e также рассчитывает ранние даты — самые ранние даты
возможного старта и финиша каждой работы — и поздние даты — са-
мые поздние даты возможного старта и финиша каждой работы без за-
держки финиша проекта в целом или его промежуточных этапов.
Ограничение "Жесткий старт" — Ограничение, устанавли-
вающее даты раннего и позднего старта работы на определенную Вами
дату. P3e применяет дату жесткого старта, невзирая на то, как она по-
влияет на логику сети. Жесткая дата раннего старта может повлиять на
поздние даты всех работ, предшествующих работе, на которую наложе-
но ограничение, и на все ранние даты работ, следующих за работой, на
которую наложено ограничение.
Ограничение "Жесткий финиш" — Ограничение, устанавли-
вающее даты раннего и позднего финиша работы на определенную Ва-
ми дату. P3e применяет дату жесткого финиша, невзирая на то, как она
повлияет на логику сети. Это ограничение влияет на поздние даты всех
работ, предшествующих работе, на которую наложено ограничение, и
на все ранние даты работ, следующих за этой работой.
Ограничение "Как можно позже" — Ограничение, накладывае-
мое на работу с положительным резервом, позволяющее ей начаться как
можно позже, не задерживая своих последователей. При применении
этого ограничения P3e устанавливает ранние даты как можно позже без
влияния на работы- последователи.
Ограничение "Старт на дату" — Ограничение, накладываемое
на работу, путем назначения даты старта. Ограничение "Старт на дату"
задерживает дату раннего старта или же приближает дату позднего
старта для соответствия указанной дате ограничения. В отличие от же-
сткого ограничения по старту, которое может нарушить логику сетевого
графика, данное ограничение сохраняет ее.
Ограничение "Старт не позже, чем…" — Ограничение "Старт
не позже, чем…", назначенное на работу, определяет самую позднюю
дату старта работ. Рассчитывая расписание, P3e назначает ограничение
"Старт, не позже чем..." при расчете расписания назад, только если рас-
считанная дата позднего старта будет позже, чем назначенная дата. Это
ограничение может уменьшить полный резерв. Оно влияет только на
поздние даты.
232
Ограничение "Старт не раньше, чем…" — Накладываемое на
работу ограничение, определяющее самую раннюю дату старта работы.
При расчете расписания, P3e применяет ограничение "Старт не раньше,
чем…" при расчете расписания вперед, только если вычисленный ран-
ний старт будет раньше, чем назначенная дата. Это ограничение влияет
только на ранние даты. Дата раннего старта работы с ограничением
"Старт не раньше, чем..." не может быть раньше, чем назначенная дата,
хотя последовательность работ сетевого графика может быть причиной
более позднего начала работы.
Ограничение "Финиш на дату" — Ограничение, накладываемое
на работу, путем навязывания даты финиша. Ограничение "Финиш на
дату" может задержать ранний финиш или же приблизить поздний фи-
ниш к дате ограничения.
Ограничение "Финиш не позже, чем…" — Ограничение, на-
кладываемое на работу, определяющее самые поздние сроки, когда она
может быть завершена. Ограничение "Финиш не позже, чем…" влияет
только на поздние даты. Данное ограничение используется для обеспе-
чения выполнения работы не позднее назначенной даты.
Ограничение "Финиш не раньше, чем…" — Ограничение, на-
кладываемое на работу, определяющее самые ранние сроки, когда рабо-
та может быть завершена. Ограничение "Финиш не раньше, чем…" по-
зволяет координировать параллельные работы, обеспечивая их выпол-
нение к определенной дате. Это ограничение часто применяется к рабо-
там, имеющим несколько предшественников, которые должны завер-
шиться до следующей фазы проекта.
Определение Проекта (Project Definition Report) — документ,
определяющий проект, в том числе: каковы цели и результаты проекта;
в чём его необходимость; что должно быть сделано; как, когда, и где это
должно быть сделано; что для этого нужно; сколько это будет стоить;
какие необходимо привлечь внешние ресурсы и организации; какие
стандарты и процедуры подлежат соблюдению при осуществлении про-
екта [НТК].
Организационная структура (OBS) — это иерархическое пред-
ставление структуры управления проектами. Через ответственного ис-
полнителя, определяемого в иерархии OBS, определяются привилегии и
права доступа пользователей к узлам и проектам в иерархии структуры
проектов предприятия (EPS).
Отклонение (Deviation) — выход за пределы установленных тре-
бований. К отклонениям относятся случаи, когда результат работы не
удовлетворяет требованиям или необоснованно их превышает[QMPP].
Оценка до завершения (ETC) — Оценочная стоимость для за-
вершения работы. Рассчитывается как оставшаяся полная стоимость ра-
233
боты (Оставшаяся полная стоимость), или же, как PF * (BAC —
BCWP), в зависимости от выбранного метода расчета освоенного объе-
ма для пакета работ.
Оценка по завершении (EAC) — Оценка стоимости оставшегося
объема работ. Рассчитывается, как сумма фактической полной стоимо-
сти и стоимости до завершения; EAC = ACWP + ETC. Метод расчета
ETC зависит от выбранного метода расчета освоенного объема для па-
кетов работ.
План управления проектом (Project Management Plan) — осно-
вополагающий документ (baseline document), с которого должен начи-
наться любой проект. Содержит согласованное всеми участниками до-
кументально зафиксированное представление о проекте. В инвестици-
онных проектах – Мастер-план проекта (Project Master Plan) (УП).
Показатели — Один из методов управления проектами. Вы оп-
ределяете параметр показателя, его нижнее и/или верхнее значения, по
которым будут оцениваться данные проекта для выявления уведомле-
ний, которые необходимо контролировать. Уведомление автоматически
создается в случае, когда параметр показателя меньше или равен ниж-
него значения показателя, или же больше или равен верхнего значения
показателя. Например, для показателя Cost % of Planned Вы можете ус-
тановить верхнее значение, равное 100%. Когда фактические затраты по
выбранному элементу WBS достигнут 100% от запланированных затрат,
P3e создаст уведомление. Вы можете назначить ответственного за уве-
домления, создаваемые по показателю. Вы также можете выбрать маке-
ты контроля и назначить показателям уровни приоритета.
Показатель освоения затрат (CPI) — Показатель освоения за-
трат (CPI) = Плановая стоимость выполненных работ (BCWP) / Факти-
ческая стоимость выполненных работ (ACWP)
Предметная область (Scope) — совокупность продуктов и услуг,
производство которых должно быть обеспечено в рамках осуществляе-
мого проекта [PMBOK].
Предшественник — Работа, которая должна быть выполнена до
другой работы. Работа— предшественник определяет даты старта и фи-
ниша своих последователей. Работа может иметь несколько предшест-
венников, с каждым из которых могут быть разные зависимости.
Проблемные ситуации (Problem situations) — возникающие при
осуществлении проекта ситуации, для выхода из которых необходимо
находить оптимальные решения [НТК].
Проблемы проекта (Project Problems) — любой функциональ-
ный, технический или связанный с бизнесом вопрос, который возник в
процессе осуществления проекта и требует изучения и решения для то-
го, чтобы проект мог идти так, как запланировано.
234
Проект —
• уникальный процесс, состоящий из набора взаимоувязанных и
контролируемых работ с датами начала и окончания и предприня-
тый, чтобы достичь цели соответствия конкретным требованиям,
включая ограничения по времени, затратам и ресурсам [ISO].
• целенаправленная деятельность временного характера, предназна-
ченная для создания уникального продукта или услуги [НТК].
• уникальный комплекс взаимосвязанных мероприятий для дости-
жения заранее поставленных целей при определенных требовани-
ях к срокам, бюджету и характеристикам ожидаемых результатов.
Проектные отклонения (Project Exceptions) — несовпадения
фактических и плановых результатов проекта, причины таких несовпа-
дений, методы и технологии, позволяющие справляться с такими ситуа-
циями в проекте. Включают в себя риски, проблемы и изменения.
Проектные риски (Project Risks) —
• возможность возникновения непредвиденных ситуаций или рис-
ковых событий в проекте, которые могут негативно или позитивно
воздействовать на достижение целей проекта. Риск проекта харак-
теризуется следующими факторами: источниками и характеристи-
ками событий, которые могут оказать влияние на его выполнение;
вероятностями появления таких событий; возможным ущербом
проекту и оценкой его влияния на проект.
• в самом общем понимании – это опасность нежелательных откло-
нений от ожидаемых состояний в будущем, из расчета которых
принимаются решения в настоящем [УПП].
Работа типа веха — Работа типа веха отмечает начало или окон-
чание крупной фазы или этапа проекта. Веха не имеет длительности,
поэтому её иногда называют "работой с нулевой длительностью". Даты
старта и финиша вехи имеют одинаковые значения.С вехой можно свя-
зать документы. На веху можно назначить расходы, но нельзя назначить
ресурсы, роли или распределенные во времени стоимости, например,
трудозатраты.
Работа типа Гамак — Длительность работы типа гамак зависит
от ее предшественников и/или последователей. На работу такого типа
не может быть назначено никаких ограничений. При выравнивании ре-
сурсов, P3e не учитывает работы типа гамак. Работы типа гамак исполь-
зуются для задач, зависящих от других работ. Например, Вы можете
сделать работой типа гамак конторскую работу, охрану, или управлен-
ческую работу. Работа типа Level of Effort (Гамак) отличается от работы
Hammock. Даты работы Level of Effort (Гамак) зависят от дат позднего
старта и раннего финиша своих предшественников / поcледователей.
235
Даты работы Hammock зависят от дат раннего старта и позднего фини-
ша своих предшественников/последователей.
Работа, определяемая заданием — Для работы, определяемой
заданием, P3e рассчитывает назначенные ресурсы в соответствии с ка-
лендарем работы, а не с календарем ресурсов. Работы, определяемые
заданием, используются в случае, когда несколько ресурсов, назначен-
ных на одну и ту же работу должны работать вместе.
Работа, определяемая ресурсом — Ресурсы, назначенные на
данный тип работы, работают в соответствии с ресурсными календаря-
ми, а не по календарю работы. Длительность работы определяется дос-
тупностью ресурса для работы.Работы, определяемые ресурсом, исполь-
зуются в случае, когда несколько ресурсов, назначенных на работу, мо-
гут работать независимо.
Расписание проекта — плановые даты для выполнения работ и
плановые даты для наступления контрольных (ключевых) событий
(«вех») проекта [НТК].
Расчет расписания вперед — Расчет ранних дат проекта. Расчет
расписания вперед начинается с начала проекта и продолжается до его
окончания, при этом для каждой работы рассчитываются даты раннего
старта и финиша.
Расчет расписания назад — Расчет поздних дат работ проекта.
P3e начинает расчет расписания назад с самой поздней даты раннего
финиша последней работы, или же с навязанной даты финиша проекта,
если такая существует, и идет в обратном направлении до первой рабо-
ты проекта. P3e рассчитывает поздние даты старта и финиша каждой
работы на основании длительностей, ограничений и зависимостей.
Решение проблем (Problem Solving) — определение последова-
тельных систематических процедур, с помощью которых анализируют-
ся и решаются проблемные ситуации [НТК].
Риск — потенциальная, численно измеримая возможность небла-
гоприятных ситуаций связанных с ними последствий в виде потерь,
ущерба, убытков [УП].
Родительский ресурс — Ресурс, включающий в себя другие ре-
сурсы более низкого уровня.
Родительский элемент — Элемент иерархии WBS или OBS, со-
держащий другие элементы более низкого уровня.
Руководитель проекта (Project manager) — менеджер, отвечаю-
щий за успешную реализацию проекта, взаимодействие с Заказчиком,
субподрядчиками и подразделениями Компании, организацию подго-
товки и предоставление отчетности по проекту.
Содержание и границы проекта (Project Scope) – цели и задачи
проекта, основные результаты, критерии оценки того, что работа или ее
236
часть выполнена (букв. пределы, рамки, сфера). Содержание работ и ре-
зультаты проекта (или его части). Проект описывается путем перечис-
ления всех выполняемых работ, необходимых ресурсов и конечных ре-
зультатов, включая требования к качеству [УП].
Спонсор проекта – отдельный человек или организация, для ко-
торых проект предпринят и которые в наибольшей степени принимают
на себя проектный риск [BS2].
Стоимостной показатель выполнения расписания (SPI) —
Стоимостной показатель выполнения расписания (SPI) = Плановая
стоимость выполненных работ (BCWP) / Плановая стоимость работ по
графику (BCWS)
Структура декомпозиции работ (WBS) — Иерархическая струк-
тура работ, которые должны быть выполнены для осуществления про-
екта. WBS структурирована по уровням элементов проекта, начиная с
самого продукта, а затем разделяется на этапы работы.
Структура декомпозиции работ (Work Breakdown Structure),
СДР (WBS) - представление проекта в виде иерархической структуры
работ, полученной путем последовательной декомпозиции. СДР пред-
назначена для детального планирования, оценки стоимости и обеспече-
ния персональной ответственности исполнителей.
Структура проектов предприятия (EPS) — Иерархическая
структура проектов предприятия.EPS. Используется для бюджетирова-
ния сверху— вниз, многопроектного управления, определения структу-
ры проектов и определения прав доступа к информации.
Структура разбиения работ — иерархическая структура после-
довательной декомпозиции проекта на подпроекты, пакеты работ раз-
личного уровня пакеты детальных работ [УП],
Структурная декомпозиция работ — иерархическая структури-
зация работ проекта, ориентированная на основные результаты проекта,
определяющие его предметную область. Каждый нижестоящий уровень
структуры представляет собой детализацию элемента высшего уровня
проекта. Элементом проекта может быть как продукт, услуга, так и па-
кет работ или работа [НТК].
Текущая дата — Дата, используемая P3e в качестве исходной
точки при расчете расписания.
Узел EPS — Уровень, находящийся выше проекта в иерархии
EPS.
Управление проектами (Project Management) — профессио-
нальная творческая деятельность по руководству людскими и матери-
альными ресурсами путем применения современных методов, средств и
искусства управления для успешного достижения заранее поставленных
целей при определенных требованиях к срокам, бюджету и характери-
237
стикам ожидаемых результатов проектов, осуществляемых в рыночных
условиях в социальных системах. Управление проектом включает пла-
нирование, организацию, мониторинг и контроль всех аспектов проекта
в ходе непрерывного процесса достижения его целей [ISO].
Управление проектом — процесс применения знаний, навыков,
методов и средств и технологий к проектной деятельности с целью дос-
тижения или превышения ожиданий участников проекта [PMBOK].
Устав Проекта (Project Charter) — документ, разработанный
вышестоящей администрацией, который предоставляет менеджеру про-
екта право использовать ресурсы организации для выполнения работ
проекта [PMBOK].
Участники проекта — физические лица и организации, которые
непосредственно вовлечены в проект или чьи интересы могут быть за-
тронуты при осуществлении проекта [PMBOK].
Целевой план — Зафиксированный план проекта. Этот план яв-
ляется целью, относительно которой вы можете контролировать стои-
мость проекта, выполнение графика и т.д.
Цели (Scope) — совокупность продуктов и услуг, намеченных к
производству в проекте [ОУП].
Activity (Операция) — Элемент проекта, на исполнение которого
назначаются ресурсы.
Activity Definition (Определение состава операций) — Опреде-
ление перечня операций, выполнение которых необходимо для получе-
ния результатов проекта.
Activity Description (Описание операции) — Короткое описание
операции, используемое в диаграммах проекта.
Actual Cost of Work Performed (ACWP) (Фактическая стои-
мость выполненных работ (ФСВР)) — Фактические затраты за опре-
деленный период. ФСВР может определяться для проекта в целом, фа-
зы, задачи или произвольной группы фаз и задач.
Actual Start (Фактическое начало) — Дата начала выполнения
работы.
Administrative Closure (Административное завершение) —
Подготовка, сбор и распределение информации, формализующей за-
вершение проекта.
Assignment (Назначение) — Назначение ресурса на исполнение
работ операции.
Availability (Доступность) — Имеющееся в наличии количество
ресурсов в течение заданного временного интервала.
Baseline (Исходный план) — Набор характеристик проекта, со-
держащих сведения об основных временных и стоимостных параметрах
238
работ; нужен для проведения сравнения характеристик проекта на раз-
личных этапах его жизненного цикла.
Baseline Duration (Плановая длительность) — Плановая дли-
тельность задачи на момент принятия исходного плана Базовая дли-
тельностьВ MS Project используется термин Task (Задача).
Budget At Completion (ВАС) (Бюджет на завершение) — Пла-
новая стоимость проектаБюджет по завершению (БПЗ).
Budgeted Cost of Work Performed (BCWP) (Базовая стоимость
выполненных работ (БСВР)) — Параметр, используемый при анализе
по методике освоенного объема, который обозначает запланированную
по исходному (или базовому) плану стоимость работ, которые были вы-
полнены к моменту анализа. БСВР иногда называется освоенным объе-
мом.Вариант названия: Baseline Cost of Work Performed. Базовая стои-
мость выполненных работ (БСВР).
Budgeted Cost of Work Scheduled (BCWS) (Базовая стоимость
запланированных работ (БСЗР)) — Параметр используется при ана-
лизе хода работ по методике освоенного объема и обозначает сводную
стоимость работ, которые должны были быть осуществлены к моменту
анализа. Другими словами, параметр обозначает, каковы должны быть
затраты на проект на текущий момент по исходному (базовому) пла-
ну.Вариант названия: Baseline Cost of Work Scheduled.Базовая стоимость
запланированных работ (БСЗР).
Change Control (Управление изменениями) — Применение
корректирующих воздействий, если это необходимо по результатам
анализа исполнения.
Change Control Board (CCB) (Совет управления изменениями)
— Формальная группа участников проекта, ответственная за принятие
или отказ в утверждении запросов на изменения.
Change Management (Управление изменениями) — Совокуп-
ность процессов, связанных с обеспечением защиты проекта от возмож-
ного негативного влияния внешних и внутренних факторов, внесением
необходимых скоординированных изменений и контроль за их эффек-
тивным осуществлением.
Communication Planning (Планирование взаимодействия) —
Определение потребностей в информации и взаимодействии участников
проекта.
Communications Management (Управление коммуникациями)
— Совокупность процессов, обеспечивающих своевременные сбор, на-
копление, распространение, хранение и последующее использование
информации проекта
Communications Planning (Планирование коммуникаций) —
Один из процессов управления проектом, заключающийся в определе-
239
нии информационных и коммуникационных потребностей участников
проекта и заинтересованных лиц, и разработке мероприятий по их удов-
летворению.
Conflict Management (Управление конфликтами) — Совокуп-
ность процессов, в которых с помощью использования управленческих
технологий решаются различные несогласования, возникающие в рам-
ках работы над проектом.
Contingency Planning (Планирование с учетом неопределенно-
стей) — Разработка плана проекта с определением альтернативных
стратегий на случай наступления рисковых событий.
Contingency Reserve (Резерв на непредвиденные обстоятельст-
ва) — Специально зарезервированные количества для тех событий
проекта, информация о которых недостаточна для тщательного плани-
рования.
Corrective Action (Корректирующее воздействие) — Измене-
ния, вносимые для приведения прогноза выполнения проекта в соответ-
ствие с планом.
Cost Budgeting (Разработка бюджета) — Приложение стоимост-
ных оценок к элементам проекта.
Cost Control (Управление стоимостью) — Управление измене-
ниями бюджета проекта.
Cost Estimating (Стоимостная оценка) — Оценка стоимости
операций проекта.
Cost Management (Управление стоимостью) — Совокупность
процессов, необходимых для соблюдения утвержденного бюджета про-
екта, планирования ресурсов, оценке стоимости, формирования сметы и
контроля стоимости.
Cost of Quality (Стоимость качества) — Стоимость управления
качеством.
Cost Variance (CV) (Отклонение по стоимости (ОПС)) — Па-
раметр, использующийся для анализа по метождике освоенного объема,
рассчитывающийся как разница между запланированными (BCWP,
БСВР) и фактическими затратами (ACWP, ФСВР) на выполнение теку-
щего объема работ.Если значение SV (ОКП) равно нулю, значит, дина-
мика расходования бюджета соответствует плану. Если значение боль-
ше нуля, значит, потрачено меньше, чем запланировано, и проект эко-
номит средства. Отрицательное значение индикатора сообщает о том,
что средства расходуются быстрее, чем предусмотрено планом.
Critical Path (Критический путь) — Последовательность работ и
зависимостей с минимальной продолжительностью, в течении которой
может быть выполнен весь комплекс работ проекта.

240