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

Содержание:

1. Корпоративное управление проектами

Работа - основной элемент дискретной деятельности, на выполнение которого требуется время и который может задержать начало выполнения других работ. Момент окончания работы означает факт получения конечного результата. На практике для ссылки на детальный уровень работ часто используется термин задача (в терминах управления проектами это синонимы).

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

Связи - логические зависимости между работами.

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

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

Временной резерв (запас времени) - разность между самым ранним возможным сроком завершения работы и самым поздним допустимым временем ее выполнения.

Анаграмма Ганга - горизонтальная линейная диаграмма, на которой задачи проекта представляются протяженными во времени отрезками, характеризующимися датами начала и окончания, задержками и другими временными параметрами.

Структура разбиения работ - иерархическая структура последовательной декомпозиции задач проекта на подзадачи.

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

Ресурсная гистограмма - гистограмма, отображающая потребности проекта в том или ином виде ресурсов в каждый момент времени.

Ресурсное календарное планирование - планирование сроков начала работ при ограниченных наличных ресурсах.

Анализ реализуемости проекта - понятие реализуемости имеет ряд своих разновидностей: логическая реализуемость, временной анализ, физическая (ресурсная) реализуемость, финансовая реализуемость.

Исходный план - план выполнения работ проекта, содержащий исходные сведения об основных временных и стоимостных параметрах работ, который принят к исполнению.

2. Системы управления проектами

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

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

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

- возможность интеграции с другими информационными системами организации;

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

- управление рисками;

- поддержку различных методик планирования и контроля работ проекта;

- поддержку множества целей;

- анализ портфелей проектов;

- многопользовательскую работу;

- распределенную работу с информацией.

3. Систем управления проектами.

Выделены две группы программных продуктов.

1. системы начального уровня (иначе называются системами календарного планирования и контроля - СКПК) стоимостью до $800;

2. профессиональные системы управления проектами, стоимость которых может превышать $5000.

Отличительными чертами программного обеспечения СКПК являются:

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

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

- поддержка всех видов связей, типов работ, типов ресурсов (возобновляемые, невозобновляемые);

- способность работать с иерархической структурой работ (WBS -Work Breakdown Structure);

- возможность выполнения выборки, сортировки, группировки, суммирования по кодам WBS и ID (идентификаторам) работ;

- поддержка основных видов визуального представления (диаграмма Ганта, PERT-диаграмма, таблица работ/ресурсов, таблица связей, гистограммы ресурсов).

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

- средства проектирования структуры работ проекта;

- средства планирования по МКП;

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

- некоторые возможности стоимостного анализа;

- средства контроля за ходом исполнения проекта;

- средства создания отчетов и графических диаграмм.

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

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

4. MS Project

Расширенное семейство продуктов Microsoft Project сочетает в себе средства управления проектами, доступа к информации и поддержки коллективной работы, а также является мощной платформой управления проектами. Новое семейство Microsoft Project (последняя версия 24 сентября 2018 года) состоит из следующих продуктов:

- Microsoft Project Standard (Однопользовательская версия для небольших проектов);

- Microsoft Project Professional (корпоративная версия продукта, поддерживающая совместное управление проектами и ресурсами, а также управление портфелями проектов с помощью Microsoft Project Server.);

- Microsoft Project Web Application (Web-интерфейс для простого редактирования проектов, отчетности о выполнении задач, а также просмотра портфелей проектов и отчетов.).

-Microsoft Project Portfolio Server (продукт для отбора проектов для запуска на основе сбалансированных показателей, вошел в состав Microsoft Project Server с версии MS Project 2010, Начиная с 2013 года Microsoft начинает поставлять облачную версию Microsoft Project Online.)

Среди механизмов управление ресурсами в Microsoft Project можно отметить:

- блокировки пула ресурсов;

- связь пула ресурсов с MS Exchange и Active Directory;

- поиск ресурсов по признакам и занятости;

- корпоративный пул ресурсов;

- ролевые ресурсы;

- мастер оптимизации ресурсов;

- Web-центр управления ресурсами.

Впервые Microsoft оборудовала свой проектный инструментарий средствами моделирования корпоративного класса «что-если?». Используя Portfolio Modeler, можно проанализировать, как разные сценарии развития проектов скажутся на сроках, себестоимости, загрузке ресурсов и т. д.

5. Spider Project – первая российская система управления профессионального уровня

Операции:

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

Взаимосвязи работ:

В Spider Project используются те же типы взаимосвязей, что и в других известных пакетах. Отличия имеются в определении задержек. Наряду с положительными и отрицательными временными задержками, можно использовать и объемные задержки. При этом мы считаем использование объемных задержек предпочтительным. Действительно, проблема с временными задержками заключается в том, что если работа началась, но исполняется медленнее, чем было запланировано, временная задержка может исчерпаться раньше, чем будет выполнен запланированный объем работ. Временные задержки требуют внимания и регулярной корректировки.

Ресурс:

Отличия в задании ресурсов наиболее значительны. Ресурсы подразделяются на возобновляемые (люди, механизмы) и невознобляемые (материалы). В большинстве пакетов те и другие задаются вместе, отличия обычно заключаются лишь в задании стоимости их использования – в час или за единицу. В Spider Project эти виды ресурсов задаются отдельно. При этом можно задать, что возобновляемые ресурсы потребляют материалы (пример: автомобиль потребляет бензин). Тогда назначив ресурсы на исполнение операций проекта вы автоматически учитываете попутное потребление необходимых материалов.

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

Пулы – это группы взаимозаменяемых ресурсов. Основное отличие от подходов, используемых в других пакетах, в которых имеется skill scheduling, заключается в том, что ресурсы пула могут иметь различные производительности.

Назначения:

Очень серьезные отличия имеются в назначениях ресурсов на исполнение операций проекта. В Spider Project при назначениях ресурсов на исполнение операций проекта появляется понятие команды, то есть группы ресурсов, выполняющих работы вместе. В команду могут входить как отдельные ресурсы, так и мультиресурсы и пулы. Если у операции исходной информацией является объем работ, необходимо задать производительность хотя бы одного из назначенных ресурсов, чтобы пакет вычислил длительность работы. При этом заметим, что при назначении пулов длительность работы определяется только в процессе составления расписания работ.

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

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

Ресурсы могут быть назначены на исполнение операции частично. Тогда в Spider Project задается процентная загрузка назначенных ресурсов наряду с количеством. Тем самым не создается ситуация, обычная для других пакетов, когда необходимое количество ресурсов остается неизвестным (две единицы ресурса с 50% загрузкой в других пакетах эквивалентны одной единице, загруженной полностью). Как уже упоминалось, материалы могут потребляться ресурсами в процессе своей работы, могут быть назначены напрямую на операцию и на назначение ресурса (тогда можно получать отчетность о потреблении материалов отдельными ресурсами).

Существенным отличием Spider Project является и то, что в пакете моделируется не только потребление, но и производство ресурсов и материалов на операциях и назначениях.

Стоимости:

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

Центры:

Часто бывает необходимым контролировать группы материалов, ресурсов и затрат. Для этой цели служат центра материалов, ресурсов и стоимостей, которые в Spider Project можно создавать в неограниченном количестве. В центр материалов можно включить любую группу материалов, в центр ресурсов – группу ресурсов и получать отчеты об общем количестве ресурсов или материалов по соответствующему центру.

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

Иерархические структуры:

В Spider Project можно использовать неограниченное количество различных иерархических структур работ и ресурсов. Использование множественных иерархических структур мы считаем принципиальным, а споры вокруг того, какую именно иерархическую структуру считать оптимальной, беспредметными. Поэтому нам не понятна цель работы той группы в комитете стандартов PMI, которая разрабатывает рекомендации по структуризации проектов. Использование множественных иерархических структур позволяет не только получать отчетность о проектах в самых различных разрезах, но и проконтролировать полноту компьютерной модели проекта.

Как правило, мы используем в наших проектах по меньшей мере следующие три иерархические структуры работ – по объектам проекта, по процессам проекта, по ответственности исполнителей. При этом следует подчеркнуть, что структура ответственности с успехом заменяет матрицу ответственности, обычно разрабатываемой в плане проекта. Ответственности как правило распределяются иерархически и только в небольших проектах структура ответственности становится плоской и может быть сведена к матрице. Кроме того, в пакете Spider Project можно создавать и другие структуры работ, в том числе неполные (не содержащие всех операций проекта).

Неполные структуры – удобный инструмент для подготовки отчетности и анализа отдельных аспектов проекта. Примерами таких неполных структур могут служить структура поставок, в которую входят только те операции, которые отображают поставки материалов, или структура Milestones, включающая только контрольные события проекта (Milestone schedule). Использование иерархических структур ресурсов особенно важно при мультипроектном управлении. При этом матричная структура организации определяет необходимость получения отчетности по ресурсам как по проектной иерархии, так и по функциональной. Поэтому и для ресурсов полезно использовать множественные иерархические структуры.

Вычесления:

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

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

- разработку расписания исполнения проекта с учетом ограниченности ресурсов (leveling)

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

- определение потребности проекта в финансировании, материалах и оборудовании в любые периоды времени

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

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

- ведение учета исполнения

- анализ отклонений хода работ от запланированного (в том числе Earned Value Analysis) и прогнозирование основных параметров проекта

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

Критический путь и резерв:

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

В качестве примера приведем простой проект, состоящий из трех операций – у двух операций плановая длительность по десять дней, у третьей – пятнадцать. Первые две для своего исполнения требуют ресурса А, третья – ресурса В. Если операции не взаимосвязаны, то третья операция является критической в классическом понимании, а у двух первых имеется полный резерв в пять дней. Если же рассчитать расписание с учетом того, что имеется лишь по одной единице каждого из ресурсов, первые две операции можно выполнять лишь по очереди, а у третьей возникает резерв в пять дней. Поэтому в Spider Project вычисляется ресурсный критический путь и резервы сроков исполнения операций с учетом ограниченности ресурсов.

Мы довольно давно предлагали эту концепцию (в частности, в презентациях на конференциях PMI и конгрессе IPMA в Париже в 1996 году) и рады тому, что сейчас концепции ресурсного критического пути стали уделять внимание. Имея возможность определения и использования ресурсного критического пути и ресурсных резервов, мы критически относимся к теории Critical Chain.

Ведение учета исполнения:

Учет исполнения и корректировка расписания оставшихся операций проекта в пакете Spider Project также отличается от общепринятого. Прежде всего, учет основан на регистрации не только отработанной длительности, но и выполненных объемов. Это позволяет пакету рассчитать длительности и расписание исполнения оставшихся операций проекта, основываясь на объективной информации. Учет выполненных объемов и отработанной длительности позволяет откорректировать первоначальные оценки производительности ресурсов проекта и соответственно скорректировать расписание исполнения оставшихся операций. Пакет ведет архивы учета и предоставляет пользователям возможность получать отчетность по исполнению за любой промежуток времени и по любой иерархической структуре работ проекта.

Заключение:

В России выработаны собственные подходы к управлению проектами в России, которые отличаются от принятых в других странах и описанных в A Guide to the PMBOK. Эти отличия нашли свое отражение и в Российском пакете управления проектами Spider Project.

Из основных особенностей этого пакета отметим:

- возможность составления расписания проекта, основываясь на физических объемах работ и производительности ресурсов

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

- включение в модель проекта поставок и финансирования и расчет расписания с их учетом

- расчет и использование ресурсного критического пути и ресурсных резервов

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

- использование множественных иерархических структур работ и ресурсов проекта

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

- дополнительные формы графических отчетов

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

Интересно то, что Российским менеджерам трудно использовать Американские пакеты управления проектами, которые не поддерживают технологию управления, принятую в России. Русские менеджеры не верят, что можно управлять серьезными проектами, отказавшись от таких фундаментальных в России понятий, как объем работ и производительность ресурса. С учетом имеющихся тенденций к глобализации, необходимо выработать взаимопонимание и унификацию подходов к процессам управления проектами.

Список Литературы:

В.Либерзон, И.Лобанов https://blog.iteam.ru/spider-project-pervaya-rossijskaya-sistema-upravleniya-professionalnogo-urovnya/

https://works.doklad.ru/view/KecUn4wkiQQ/2.html

https://ru.wikipedia.org/wiki/Microsoft_Project

- Элейн Мармел. Microsoft Office Project 2007. Библия пользователя. Управление проектами = Microsoft Office Project 2007 Bible. — М.: «Диалектика», 2008. — С. 800. — ISBN 978-5-8459-1400-2.

- Сингаевская Галина Ивановна. Управление проектами в Microsoft Project 2007. — М.: «Диалектика», 2008. — С. 800. — ISBN 978-5-8459-1374-6.

- Бонни Бьяфоре. Все по плану! Успешное управление проектами с использованием Microsoft Project = On Time! On Track! On Target!: Managing Your Projects Successfully with Microsoft Project. — М.: Microsoft Press, 2006. — С. 304. — ISBN 5-7502-0293-3.