Добавлен: 05.07.2023
Просмотров: 39
Скачиваний: 1
Существенным отличием 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.
Из основных особенностей этого пакета отметим:
- возможность составления расписания проекта, основываясь на физических объемах работ и производительности ресурсов
- опимизация использования ресурсов проекта и широкие возможности моделирования их работы