[ Программные средства управления проектами
Часть 1: Планирование
Либерзон В.И., PMP
1. Введение
Программы управления проектами уже давно образуют отдельный рынок
программного обеспечения, который только недавно начал привлекать внимание в
России. Такие программы в мире установлены на миллионах компьютеров, обзоры
этого рынка регулярно печатаются в западных компьютерных изданиях, появились наконец и обзоры в наших журналах [1, 2]. Тем не менее, этот класс программ – один из наиболее интересных для российских пользователей. В нашей стране крайне мало стабильно работающих предприятий, проекты есть везде и от того, насколько удачно они будут управляться, зависит не только будущее отдельных предприятий, но и страны в целом.
Появление программ управления проектами способствовало преобразованию искусства управления проектами в науку, в которой имеются четкие стандарты, методы и технологии. Так стандаот, разработанный Институтом управления проектами (Project Management Institute) принят в качестве национального стандарта в США (стандарт ANSI), появился и стандарт по качеству в управлении проектами ISO 10006. Применение этих технологий способствует своевременной реализации проектов в рамках выделенных бюджетов и с требуемым качеством. Мы рассмотрим программы управления проектами наряду с технологией их применения, что будет способствовать и лучшему пониманию их особенностей и различий, и лучшему пониманию того, как их можно и нужно использовать. Конечно, программы управления проектами – это только инструмент менеджера проекта, а управление проектом не сводится к компьютерному моделированию. Мы не будем затрагивать те аспекты управления проектами, которые этими инструментами не поддерживаются.
Первая часть статьи посвящена созданию детерминированной компьютерной модели проекта, составлению расписания исполнения работ и бюджетированию проектов. Во второй части будут рассмотрены анализ рисков и неопределенности, организация учета и анализа исполнения.
2. Назначение Программы управления проектами можно использовать по разному. Для одних это инструмент для компьютерного моделирования проектов и просчета последствий принимаемых решений до их реализации, для других – средство отображения директивных показателей проекта и подготовки красивой отчетности.
Первый тип пользователей называют профессионалами, второй тип – это обычно люди, для которых управление проектами не их бизнес. Соответственно позиционируются и программы управления проектами, которые делятся на два основных класса – профессиональные (high end) и непрофессиональные (low end).
Основное отличие этих программ друг от друга заключается в их возможностях по моделированию работы ресурсов проекта, учету и моделированию рисков, структуризации проектной информации, управлению совокупностью проектов (мультипроектом).
Итак, профессионалы используют программы управления проектами для решения следующих основных задач:
- Структуризации и описания состава и характеристик работ, ресурсов, затрат и доходов проекта, - Расчета расписания исполнения работ проекта с учетом всех имеющихся ограничений, - Определения критических операций и резервов времени для исполнения других операций проекта, - Расчета бюджета проекта и распределения запланированных затрат во времени, - Расчета распределения во времени потребности проекта в основных материалах и оборудовании, - Определение оптимального состава ресурсов проекта и распределения во времени их плановой загрузки, - Анализа рисков и определения необходимых резервов для надежной реализации проекта, - Определения вероятности успешного исполнения директивных показателей, - Ведения учета и анализа исполнения проекта, - Моделирования последствий управленческих воздействий с целью принятия оптимальных решений, - Ведения архивов проекта, - Получения необходимой отчетности по проекту.
Непрофессиональное использование программ управления проектами чаще всего сводится к - составлению расписания исполнения работ проекта без учета ресурсных ограничений при директивных, а не расчетных продолжительностях его работ, - заданию директивных значений затрат проекта, - выдаче планов работ для ресурсов проекта, - упрощенному учету исполнения, - контролю исполнения запланированных показателей и анализу отклонений.
В некоторых простых и не слишком важных проектах этой информации может быть достаточно для управления, но мы в дальнейшем будем ориентироваться на профессионалов.
3. Пакеты управления проектами В этом обзоре мы остановимся на пакетах, представленных на российском рынке. Таких пакетов немного, но в России представлены наиболее популярные пакеты разных секторов рынка. Непрофессиональные пакеты обычно стоят около $500 и представлены чемпионом по продажам – пакетом Microsoft Project (компания Microsoft, www.microsoft.com), а также пакетами Suretrak Primavera Systems, www.primavera.com) и Spider Project Lite (Технологии управления Спайдер, www.spiderproject.ru), профессиональные стоят свыше $3000 и представлены пакетами Primavera Project Planner (P3) - $4000, Primavera Project Planner Enterprise (P3e) - $5000 (оба Primavera Systems), Open Plan Professional - $6000 (Welcom Software Technologies, www.welcom.com) и Spider Project Professional - $ (Технологии управления Спайдер). У пакетов Open Plan и Spider Project имеются версии Desktop стоимостью $1000, которые представляют собой урезанные по функциям версии пакетов Professional. Основное отличие пакетов Desktop от пакетов Professional в том и другом случае – отсутствие инструментов групповой работы с моделями проектов. То есть эти пакеты предназначены для тех пользователей, которые управляют отдельными проектами (подпроектами), но не занимаются мультипроектным управлением. За исключением российского пакета Spider Project, все остальные перечисленные пакеты выпускаются американскими компаниями.
Из пакетов, не представленных на нашем рынке, заслуживают упоминания Scitor Project Scheduler – пакет непрофессионального сегмента рынка, который является основным соперником MS Project на западном рынке, а также Artemis Project View – наиболее мощный из западных профессиональных пакетов управления проектами. Artemis Project View работает с базой данных Oracle, довольно дорог и при этом достаточно неповоротлив. Его дополнительные возможности невелики, а стоимость в несколько раз выше стоимости других профессиональных пакетов. Потому популярность пакета не высока и на Западе.
В начале 90-х годов в России был довольно популярен пакет Time Line, но в настоящее время этот пакет практически ушел с рынка, новых версий не выпускалось лет 7, на выставках последних лет пакет не представлен.
Среди перечисленных пакетов большинство американские, которые разрабатывались и развивались в условиях плотной конкуренции друг с другом. В результате в этих пакетах схожие подходы, возможности, методологии. Особняком стоит Spider Project – пакет, разработанный российской компанией Teхнологии управления Спайдер. В этом пакете много нетрадиционных решений, уделяется особое внимание математическому моделированию проекта и поиску оптимальных решений. Кроме того, пакет включает ряд подходов к моделированию проекта, которые востребованы на нашем рынке и отсутствуют в американских пакетах (например, планирование и контроль физических объемов работ, производительностей ресурсов и т.д.). Особенности пакета будут отмечены в описании реализации различных функций управления проектами программами управления проектами.
4. Технология компьютерного моделирования Для создания компьютерной модели проекта необходимо проделать следующие шаги:
1) Укрупненно описать проект – создать Иерархическую структуру работ, 2) Задать, какие составляющие стоимости будут использованы для финансового анализа и управления проектом, 3) Составить перечень операций (работ, задач) проекта и задать их характеристики, 4) Составить перечень ресурсов проекта и задать их характеристики, 5) Задать взаимосвязи (ограничения на порядок исполнения) операций проекта, 6) Назначить ресурсы на исполнение операций проекта, 7) Назначить стоимости на операции, ресурсы и назначения проекта, 8) Задать ограничения на финансирование, поставки, сроки исполнения операций, 9) Составить расписание исполнения работ проекта с учетом всех ограничений, 10) Оптимизировать состав используемых ресурсов, 11) Определить бюджет и распределение во времени плановых затрат проекта, 12) Определить и промоделировать риски и неопределенности, 13) Определить необходимые резервы на сроки, стоимости и потребности в материалах для исполнения запланированных показателей с заданной надежностью, 14) Если заданы директивные сроки, стоимости, ограничения по поставкам, то определить вероятность их успешного соблюдения, 15) Представить плановую информацию руководству и исполнителям.
В процессе исполнения необходимо:
1) Вести учет, 2) Анализировать отклонения исполнения от запланированного, 3) Прогнозировать будущие параметры проекта, 4) Моделировать управленческие воздействия, 5) Вести архивы проекта.
Далее мы рассмотрим перечисленные шаги по порядку и проанализируем возможности различных пакетов управления проектами.
5. Иерархическая структура работ проекта Создание компьютерной модели проекта всегда начинается с разработки Иерархической Структуры Работ (Work Breakdown Structure). Реальные проекты состоят из тысяч операций, описать их все и ничего не пропустить без структуризации (разбиения проекта на подпроекты, фазы, подфазы, пакеты работ) практически невозможно. Процесс разработки ИСР называется декомпозицией целей [3].
Наиболее распространенный подход к структуризации – разбиение проекта на подпроекты, фазы, и т.д. исходя из объектов проекта. Так, чтобы произвести велосипед вы должны сделать раму, колеса, тормозную систему и т.д. Подразделив проект на объекты с максимальной разумной детализацией вы должны описать процессы, связанные с реализацией каждого объекта. Однако возможны и другие подходы к созданию Иерархической структуры работ. Так, например, можно начать с процессов, а затем описывать, к каким объектам эти процессы следует приложить в данном проекте. Еще одна полезная структура – структура ответственности, в которой операции проекта соотносятся лицам, отвечающим за их исполнение.
Иерархические структуры работ позволяют получать отчетность по любым своим элементам. Таким образом, структура объектов позволяет подводить «Итого»
по объектам проекта, структура процессов – по процессам проекта, а структура ответственности – контролировать, как участники проекта справляются с работами в своих зонах ответственности.
Одну Иерархическую структуру работ можно завести в любом пакете управления проектами. Как уже упоминалось, без иерархии работ не удастся полностью описать операции проекта и без этой функции компьютерное моделирование проектов просто теряет смысл.
Наложение на один проект одновременно нескольких иерархических структур поддерживается пакетами Spider Project Professional и Desktop. В других профессиональных пакетах и в MS Project начиная с 2000 версии, можно заводить дополнительные иерархические коды для последующей группировки операций проекта. Это позволяет контролировать исполнение проекта с разных углов зрения, получать «итого» в произвольных разрезах.
6. Составляющие стоимости Структуризация стоимости проекта позволяет проводить финансовый анализ проекта в необходимых разрезах. Однако задать не только стоимости работ и ресурсов, но и составляющие стоимости проекта, причем в разных валютах, можно только в пакетах линейки Spider Project. В качестве примера составляющих затрат приведем зарплату, накладные расходы, стоимость материалов, оборудования, механизмов, непредвиденные расходы и т.д. Обычно в качестве отдельных составляющих стоимости вводятся те, которые относятся к финансированию проекта.
Кроме отдельных составляющих стоимости, в профессиональных версиях Spider Project можно вводить центры стоимостей, объединив в них группы составляющих стоимости. При этом можно учитывать затраты только по выбранной части ресурсов и материалов. Это позволяет вести параллельный подсчет затрат в разных единицах измерения (например, вести планирование и учет затрат параллельно в разных валютах, в текущих ценах и ценах 1984 года и т.п.).
7. Операции проекта Характеристики операций проекта определяют и те показатели, который в дальнейшем используются для моделирования проекта. Перечислим основные исходные параметры, которые можно задать и использовать при моделировании исполнения операций проекта:
- Длительность исполнения, - Объем работ на операции, - Трудоемкость операции (ресурсо-часы, необходимые для ее исполнения), - Календарь операции, - Прямые затраты на операцию, - Тип операции (что является исходной информацией – длительность, трудоемкость, или объем работ, или операция исполняется неопределенное время – от одного события до другого, или операция является вехой или контрольным событием, то есть имеет нулевую длительность и определяет важные события проекта, например завершение исполнения фаз), - Ограничения на сроки исполнения операции (например, начало не раньше определенной даты).
Во всех пакетах можно задать длительность операции, или ее трудоемкость (длительность будет подсчитана как частное от деления трудоемкости на количество назначенных ресурсов). В пакетах линии Spider Project (Lite, Desktop и Professional) можно также задать объем работ на операции в физических единицах, а длительность при этом будет рассчитана пакетом исходя из производительности назначенных ресурсов в процессе составления расписания работ.
Календарь операции определяет промежутки времени, когда операцию можно исполнять. Так, например, некоторые операции можно исполнять только в дневное время, другие – только летом и т.п. Календарь операции используется как ограничение при составлении расписания исполнения работ проекта. Задать календарь операции можно во всех пакетах, но используются они при составлении расписания по разному. В большинстве пакетов время исполнения работы определяется или календарем операции, или календарем назначенных ресурсов. В Spider Project играет роль и то, и другое. Только в рабочие периоды и операции, и назначенных ресурсов операция может исполняться.
Прямые фиксированные затраты на операцию могут задаваться в любом пакете. Кроме расходов во всех вариантах, в Spider Project можно задавать и доходы на операциях, причем использовать неограниченное количество составляющих стоимости и разные валюты.
Основные типы операций, поддерживаемые всеми пакетами:
– с фиксированной длительностью, - с фиксированной трудоемкостью (длительность – частное от деления трудоемкости на количество назначенных определяющих (driving) ресурсов), - гамак (hammock) – такие операции длятся от выполнения связи на старт до выполнения связи на финиш, то есть от события и до события, - вехи или контрольные события (milestones) – операции нулевой длины, обычно отражающие наступление важных событий проекта, таких как окончание фазы и т.п.
В MS Project операций типа гамак нет, но зато можно использовать в качестве гамаков фазы ИСР. В отличие от других пакетов, в которых фазы – это «итого» по операциям, которые в них входят, в MS Project на фазы можно назначать ресурсы, то есть использовать их наподобие гамаков.
Вехи и ограничения на сроки исполнения операции можно задавать в любом пакете.
В Spider Project имеются также операции, у которых задается объем, а длительность вычисляется исходя из производительности назначенных ресурсов (операция типа «производительность»).
Кроме того, в пакетах Spider Project и Open Plan можно задать, допускает ли операция прерывание своего исполнения, если ресурсы, исполняющие операцию, требуются на других, более приоритетных работах.
8. Ресурсы проекта Ресурсы проекта можно подразделить на возобновляемые (люди, механизмы) и невозобновляемые (материалы, оборудование). Возобновляемые ресурсы можно использовать повторно после того, как они завершили работу на очередном назначении, невозобновляемые расходуются и повторно использованы быть не могут.
В большинстве пакетов те и другие ресурсы задаются вместе в едином перечне ресурсов, в пакетах Spider Project задание возобновляемых и невозобновляемых ресурсов разнесено в разные таблицы и они представляют собой разные объекты программы. Это вызвано не только тем, что по этим ресурсам задаются разные характеристики, но и тем, что в Spider Project можно задавать потребление материалов возобновляемыми ресурсами в процессе своей работы (расход электроэнергии, горюче-смазочных материалов и т.п.), чего в других пакетах делать нельзя.
К основным характеристикам возобновляемых ресурсов относятся:
- общее количество, - стоимость часа работы (обычной и сверхурочной), - календари работы ресурсов, - принадлежность к подразделению Иерархической Структуры Ресурсов (Resource Breakdown Structure).
В пакете MS Project общее количество ресурсов задается в процентах. Так, один ресурс можно задать как 100%, два – как 200% и т.д. Это сделано для удобства задания неполной загрузки ресурсов на работах, но не позволяет задать оба параметра одновременно – и количество назначенных ресурсов, и их загрузку на операции.
В профессиональных американских пакетах можно задавать разное наличие ресурсов в различные отрезки времени. В Spider Project можно задавать производство, а также расходование ресурсов, причем привязать то и другое не только к моментам времени, но и к операциям проекта.
Иерархическую структуру ресурсов можно задать в P3e, Open Plan и Spider Project. При этом в Spider Project можно наложить на ресурсы неограниченное количество иерархических структур, что позволяет группировать ресурсы произвольным образом и получать отчетность по загрузке ресурсов во всевозможных матричных структурах управления.
Во всех версиях Spider Project стоимость часа работы возобновляемых ресурсов можно задавать по составляющим затрат (например, зарплата, накладные расходы, амортизация и т.п.), однако отсутствует возможность задания уровня оплаты сверхурочных работ – в России спрос на эту функцию отсутствует.
Кроме того, в Spider Project можно также задать потребление материалов за час работы возобновляемого ресурса.
Все большую популярность приобретает skill scheduling (поддерживается Open Plan, Spider Project и MS Project 2002), когда ресурсам присваиваются роли, которые они могут играть, а на исполнение операций проекта назначаются не конкретные ресурсы, а роли. Программа выбирает, какие именно ресурсы выгоднее использовать на тех, или иных работах. В пакете Spider Project роли задаются через создание всевозможных пулов ресурсов и главное отличие в подходах заключается в том, что в американских пакетах ресурсы с одной ролью (skill) полностью взаимозаменяемы, в то время как в Spider Project у этих ресурсов может быть разная производительность, которая учитывается при назначении исполнителей. В этом пакете (во всех версиях) можно назначать на исполнение операции или общее количество ресурсов определенной роли, или общую производительность назначенных ресурсов, чтобы программа сама подобрала нужное количество (два СуперМАЗа или три МАЗа например).
В P3e тоже можно задать роли ресурсов, но выбор исполнителей тем не менее осуществляет человек, а не программа.
В профессиональной и Desktop версиях Spider Project еще можно задать мультиресурсы. Мультиресурсы – это устойчивые группы ресурсов, выполняющие работы только вместе (бригады, водитель и самосвал, и т.п.). Это позволяет назначать на работы не только отдельные ресурсы, но и бригады целиком, что значительно снижает трудоемкость ввода и сокращает число потенциальных ошибок. Однако главная изюминка подхода состоит в том, что можно в любой момент в одном месте изменить состав бригады и пакет пересмотрит состав всех назначений бригады автоматически. Это позволяет легко проводить анализ «что если», подбирая оптимальный состав ресурсов проекта.
По невозобновляемым ресурсам (материалам) задается стоимость за единицу. В Spider Project эта стоимость может относиться к различным компонентам затрат, а кроме того, может быть задано имеющееся начальное количество материалов, которое используется при расчете расписания с учетом ограничений по поставкам.
9. Взаимосвязи операций Взаимосвязи операций отражают ограничения на порядок их исполнения. Так, нельзя строить стены, пока не готов фундамент, нельзя укладывать трубы пока не готова траншея хотя бы на ближайшем участке.
В пакетах управления проектами поддерживаются четыре типа взаимосвязей Финиш-Старт, когда следующая работа может начинаться после завершения предшествующей, Старт-Старт, когда следующая работа может начинаться после начала исполнения предшествующей, Финиш-Финиш, когда следующая работа может завершиться только после завершения предшествующей, Старт-Финиш, когда следующая работа может завершиться только после начала предшествующей.
Кроме самого типа связи часто задается «задержка» - промежуток времени от выполнения логического условия связи до момента, когда можно начинать исполнение последующей операции. Задержка может быть как положительной, так и отрицательной, а также иметь собственный календарь (в Open Plan и Spider Project).
В пакете Spider Project имеется возможность задания не только временных, но и объемных задержек, когда следующая операция может исполняться после того, как на предшествующей выполнен определенный объем. Основные преимущества объемных задержек сказываются при исполнении проекта. Задавая временную задержку пользователи как правило прикидывают, какое время необходимо для создания достаточного задела на предшествующей операции. Это время зависит от назначенных ресурсов, да и в процессе реализации проекта может оказаться, что за плановое время необходимый задел не создан. Поэтому временные задержки требуется регулярно контролировать и пересматривать, в то время как объемные отражают первичную информацию и в процессе исполнения не изменяются.
Все перечисленные типы взаимосвязей являются связями типа «не раньше».
Исполнение последующей операции всегда можно задержать без нарушения условия связи. Однако часто бывает, что следующую операцию необходимо начинать сразу по исполнению условия связи (самолет заправщик не может долго ждать тот самолет, который следует заправить, сложно укладывать трубу в траншею, выкопанную несколько месяцев назад, и т.п.). Поэтому в пакете Spider Project появились так называемые жесткие связи, которые должны исполняться немедленно. Если заправляемый самолет будет позже, то и заправщик вылетит точно ко времени.
10. Назначение возобновляемых ресурсов Назначение возобновляемых ресурсов на исполнение операций проекта тесно связано с определением длительности операций. В зависимости от числа и производительности назначенных ресурсов длительность операции может быть разной, хотя бывают и такие операции, у которых именно длительность является исходной информацией (прогрев бетона, время на получение разрешения) и от назначенных ресурсов не зависит.
В пакетах, поддерживающих skill scheduling, на исполнение операций можно назначать не сами ресурсы, а роли и количество необходимых ресурсов, в Spider Project – пулы ресурсов. Кроме того, в Spider Project на исполнение операций можно назначать мультиресурсы, а значит и все ресурсы, которые в них входят.
К основным характеристикам назначений относятся - количество назначенных ресурсов, - производительности назначенных ресурсов (только в Spider Project), - процентная загрузка ресурса на работе (доля рабочего времени в процентах, которая расходуется на этой операции), - профиль загрузки ресурса на операции.
В американских пакетах задается общая загрузка назначенных ресурсов на исполнении операции. Пример – назначение 100% ресурса на задачу в MS Project.
Это можно интерпретировать и как назначение одного ресурса на 100% своего времени, и как назначение двух единиц ресурса с 50% загрузкой. В результате при расчете расписания ограничения на ресурсы могут быть интерпретированы неправильно. В Spider Project количество и процентная загрузка ресурсов задаются раздельно, а при составлении расписания учитывается и то, и другое.
Профиль загрузки ресурсов на операции определяет динамику использования ресурсов на операции. Например, две единицы ресурсов используются первые два дня, четыре – три последующих, одна единица - в последний день. Такое задание загрузки ресурсов позволяет описывать проект укрупненно, избегая детализации, но создает проблемы при анализе проекта и ведении учета. На самом деле изменение загрузки всегда связано с чем-то, что меняет характеристики последующей части работы. В Spider Project предлагается такую ситуацию моделировать через совокупность «жестко» связанных операций, каждая из которых обладает своими характеристиками (в частности, загрузкой ресурсов). Тогда операцию, на которой загрузка ресурсов переменная, может быть представлена в виде фазы, но при этом фазу можно раскрыть и увидеть, из каких операций она состоит, и контролировать их исполнение.
Более сложная функция – задание неизвестной заранее переменной загрузки ресурсов, поддерживаемая Open Plan и Spider Project Desktop и Professional.
Профиль загрузки подбирается пакетом исходя из потребности в назначенных ресурсах на других операциях проекта. В Spider Project при этом задается, что и количество, и процентная загрузка ресурсов на назначении может колебаться от заданных минимальных до заданных максимальных значений. В Open Plan задается максимальная длительность операции, загрузка ресурсов подбирается таким образом, чтобы ее не превзойти, иначе операция при расчете расписания откладывается.
Другая продвинутая функция, имеющаяся только в профессиональной и Desktop версиях пакета Spider Project – назначение на исполнение операций независимых команд ресурсов. В одной команде ресурсы могут работать только вместе, а вот разные команды исполняют работу независимо друг от друга. Это позволяет моделировать сменную работу. На исполнение операции назначаются команды, представляющие разные смены, а исполнять будут те, в чью смену попадет операция.
Следует отметить, что в американских пакетах отсутствует понятие стоимости назначения ресурса на исполнение операции. Однако без этой функции трудно управлять оплатой сдельных работ и работ, выполняемых по контрактам. Стоимость работы подрядчика не оценивается на почасовой основе, и без понятия стоимости назначения трудно получить отчетность по стоимости работ различныз подрядчиков. Только в пакетах линейки Spider Project фиксированная стоимость назначения может быть задана по любым компонентам затрат и в любых валютах.
11. Назначение материалов Во всех пакетах можно назначить потребление фиксированных количеств материалов на операциях проекта.
В Spider Project можно также назначить потребление фиксированных количеств материалов на назначениях возобновляемых ресурсов. Кроме того материалы могут потребляться ресурсами в процессе своей работы, если в свойствах ресурсов задано часовое потребление ими определенных материалов.
12. Поставки и финансирование Поставки и финансирование можно моделировать в пакете Spider Project.
Моделирование поставок осуществляется заданием отрицательного расхода соответствующих материалов на операциях, отображающих поставки. Для моделирования финансирования следует ввести составляющие стоимости, у которых стоимость единицы отрицательна, и назначить их на операции проекта, соответствующих поступлению финансов в проект.
Задав финансирование, можно будет получать отчеты не только по затратам проекта, но и по cash flow, а также учитывать ограничения по финансированию и поставкам при составлении расписания исполнения работ проекта (только в профессиональной версии Spider Project).
В пакете Open Plan финансирование как таковое не задается, однако можно рассчитать расписание проекта с учетом заданных ограничений по затратам проекта за определенные промежутки времени.
13. Составление расписания исполнения работ проекта Для составления расписания исполнения проекта без учета ограниченности ресурсов используется широко известный метод критического пути, позволяющий получить оптимальное решение задачи. Поэтому расписания, составленные разными пакетами при тех же исходных данных, не будут отличаться. В процессе составления расписания определяются ранние и поздние даты (старт и финиш) исполнения операций проекта, Операция не может быть начата ранее даты раннего старта, а опоздание исполнения операции по отношению к поздним датам означает задержку проекта в целом. Промежуток времени между ранним и поздним стартом операции называется полным резервом, а операции, у которых полный резерв равен нулю, называются критическими. Совокупность критических операций образует критический путь.
Критический путь без учета ограниченности ресурсов вычисляется всеми пакетами управления проектами.
Кроме расписания от начальной даты пакеты управления проектами (кроме Microsoft Project) вычисляют и расписание назад от заданной пользователем директивной даты завершения проекта. Это расписание позволяет определить, когда следует начать исполнение работ проекта, чтобы завершить его к назначенной дате.
Ситуация кардинально меняется, если при составлении расписания принимать во внимание ресурсные и стоимостные ограничения. В этом случае математические методы поиска оптимального решения не работают. В разных пакетах используются различные эвристические методы составления расписания исполнения проекта. В результате расписания, составленные для одного и того же проекта разными пакетами, могут кардинально отличаться.
В непрофессиональных пакетах (кроме Suretrak) в пакете имеется стандартный алгоритм и у пользователей нет возможности выбирать приоритетные поля. Как правило, алгоритм, используемый по умолчанию, - минимальный полный резерв операции, рассчитанный без учета ресурсных ограничений. Правда, в последних версиях MS Project отошли от традиции и используют другой алгоритм, не описав его в Руководстве пользователя.
Рис.1. Расписание проекта Test, составленное MS Project по умолчанию Новый алгоритм не сильно улучшил возможности пакета. На рис.1 приведено расписание (диаграмма Ганта) исполнения тестового проекта, составленное MS Project 2000. Этот проект можно исполнить значительно (на 14 рабочих дней) быстрее, начав исполнение с операции 1, а не с операции 3.
Пользователь может вмешаться, задав приоритеты операциям вручную, но в большом проекте ручная расстановка приоритетов – чрезвычайно трудоемкая задача, никак не гарантирующая получение оптимального решения.
Аналогичное расписание составили бы по умолчанию и профессиональные американские пакеты, однако в них пользователь может задать другие простые приоритеты назначения ресурсов. Поиграв с приоритетами можно выбрать наиболее приемлемое из предложенных пакетом расписаний.
Рис.2. Расписание проекта Test, составленное Primavera Project Planner по критерию «Исходная длительность»
Так в данном примере сработает приоритет «Исходная длительность», по которому ресурсы будут в первую очередь назначаться на операции с минимальной длительностью. На рис.2 расписание, составленное по этому критерию пакетом Primavera Project Planner (P3).
В пакетах Spider Project наряду со стандартными алгоритмами, используемыми другими пакетами, можно использовать алгоритмы оптимизации, которые хотя и не гарантируют достижения глобального оптимума, но позволяют получить более короткие и близкие к оптимальным расписания благодаря используемым итеративным эвристическим алгоритмам. Оптимальное расписание для приведенного примера в Spider Project получается по умолчанию, если использовать опцию расчета «Оптимизация».
Можно привести множество примеров, когда любые стандартные алгоритмы не дают хорошего расписания. Один из таких примеров приведен на рис.3 и 4. На рисунке 3 приведено расписание проекта Выбор программы, составленное Open Plan, на рисунке 4 расписание того же проекта, составленное пакетом Spider Project.
Расписание исполнения этого проекта, составленное Spider Project, оказывается существенно короче. Расписания, составляемые для этого проекта другими американскими пакетами, не лучше расписания Open Plan, причем стнадартные эвристики не приводят к оптимальному расписанию для этого проекта Рис.3. Расписание Open Plan для проекта Выбор ПО.
Рис.4. Оптимальное расписание Spider Project для проекта Выбор ПО.
Оптимизация расписания очень важна и позволяет сэкономить затраты за счет быстрейшего исполнения работ и сокращения накладных расходов. Однако не менее важно, чтобы составленное расписание оставалось стабильным в процессе реализации проекта. Если вы заключили контракты на поставки материалоы и привлечение рабочей силы, то внезапное кардинальное изменение расписания исполнения оставшихся работ приводит к катастрофическим последствиям для проекта.
Так, расписание проекта Тест, составленное MS Project в том случае, если на один день уменьшится длительность только одной последней операции, станет оптимальным, но будет кардинально отличаться от первоначального.
Рис.1. Расписание проекта Test, составленное MS Project при уменьшении длительности операции 4 на один день.
Как видите, изменение длительности одной операции проекта на один день приводит к изменению длительности проекта на три недели.
Поэтому в пакетах Spider Project наряду с оптимизацией расписания пользователь может также задать опцию Поддержка предыдущей версии. Тогда при расчете расписания пакет расставит такие приоритеты операциям проекта, чтобы сохранить принятый в предыдущей версии порядок их исполнения за счет отказа от оптимизации.
Из других опций составления расписания исполнения проекта отметим 1) Составлять расписание вперед или назад, то есть определить, когда проект закончится, если в определенный срок начнется, или наоборот, определить, когда его следует начать, чтобы завершить к директивной дате?
2) Допускать ли прерывание операций? При этом в MS Project и Primavera Project Planner (P3) могут прерываться либо все операции, либо ни одной, В Open Plan и Spider Project допустимость прерывания задается для отдельных операций.
Задается также сколько и какой продолжительности прерывания допустимы.
3) Учитывать или нет приоритеты операций, заданные пользователями вручную.
4) Какой временной интервал рассматривать как шаг для выравнивания ресурсов (тем самым допуская, что внутри интервала могут быть перегрузки). Эти интервалы обычно начинаются с часа, что не позволяет планировать очень короткие проекты (в частности, технологические процессы). В Spider Project такой интервал не задается, планирование всегда осуществляется с точностью до секунд.
5) Выбирается, ограничения на какие ресурсы следует учитывать, а по каким просто определить потребность.
6) Учитывать ли временные ограничения на срок завершения проекта при расчете расписания?
7) В Spider Project Professional еще выбирается, ограничения на какие материалы и стоимостные составляющие учитывать при составлении расписания.
В следующей части статьи мы разберем другие важнейшие моменты использования пакетов управления проектами. В частности, коснемся моделирования рисков, ведения учета выполненных работ, анализа отклонений хода исполнения проекта от запланированного, прогнозирования конечных показателей проекта, интерфейса, групповой работы и подведем некоторые итоги.
Литература 1. Директор Информационной службы, C10, №4, 2001. Номер посвящен программам управления проектами.
2. Виктор Терехин. «Какой С.У.П. вам нужен». Потребитель. Компьютеры и программы, №6, 2002, раздел Экспертиза и тесты.
3. A Guide to the Project Management Body of Knowledge, 2000 Edition, Project Management Institute.
С10 и №4
«