Спайдер проджект руководство пользователя

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

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

Архитектура и конфигурации пакета

Программное обеспечение Spider Project предназначено для различных групп пользователей. В его составе имеется профессиональная система Spider Project Professional, а также более дешевые версии Desktop (однопользовательский вариант профессиональной системы) и Lite (вариант с ограниченными функциональными возможностями).

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

• Spider Project Professional устанавливается в проектном офисе для мультипроектного моделирования и управления, а также в тех подразделениях, в которых принимаются решения по управлению организацией в целом (например, там, где планируется и осуществляется финансовое управление, снабжение).
• Spider Project Desktop используется для управления отдельными проектами, количество установок в организации определяется числом одновременно ведущихся проектов. Обычно на одно рабочее место Professional приходится четыре-пять рабочих мест Desktop.
• Spider Project Viewer предназначается для просмотра проектов, в этой версии не предусмотрено проведение расчетов. Обычно устанавливается у руководства. Статистика показывает, что на предприятии число используемых Spider Project Viewer примерно в два раза превосходит число используемых рабочих версий.
• Spider Project Lite ” усеченная, рассчитанная на простые проекты версия пакета, функциональные возможности которой тем не менее достаточно серьезны (стоимостные компоненты, пулы назначений ресурсов, базы данных, оптимизация расписаний и пр.).

Функциональная архитектура Spider Project и основные отличия его облегченных версий, а также другие характеристики пакета представлены на врезках.

Особенности пакета

Множественные иерархические структуры работ

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

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

ИСР по процессам на верхнем уровне использует процессы, а на более низких ” объекты проекта.

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

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

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

В Spider Project допускается использование неограниченного количества ИСР в каждом проекте, также не ограничивается количество уровней иерархии.

Множественные иерархические структуры ресурсов

Аналогично можно создавать и использовать для целей анализа и агрегации информации множественные структуры ресурсов. Это особенно важно и полезно при мультипроектном управлении.

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

Количество иерархических структур ресурсов и уровней иерархии также не ограничивается.

Компоненты стоимости и центры стоимостей, ресурсов и материалов

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

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

Моделирование доходов и производства

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

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

Моделирование работы ресурсов

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

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

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

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

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

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

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

Отметим также, что Spider Project не накладывает ограничений ни на количество ресурсов, ни на количество назначений ресурсов на исполнение операций проекта.

Особенности расчета расписания исполнения проекта

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

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

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

Ресурсный критический путь

Важной особенностью пакета является вычисление ресурсного критического пути, то есть тех операций проекта, задержка исполнения которых приводит к задержке завершения проекта, с учетом имеющихся ограничений на ресурсы. Механизм вычисления ресурсного критического пути был реализован еще в самой первой версии Spider Project в 1992 году. Критическая цепь (Critical Chain), о которой написал Голдратт в одноименной книге (Goldratt E. M. Critical Chain. North River Press, 1997) и которая сейчас широко обсуждается мировым сообществом менеджеров проектов, есть не что иное, как ресурсный критический путь. Практически все, что предлагается в теории критической цепи, реализовано в пакете Spider Project.

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

На рис. 1 проиллюстрировано понятие ресурсного критического пути и резервов времени на исполнение операций. В проекте РКП на операции 2 и 4 назначен ресурс А, который имеется в одном экземпляре, а потому они не могут исполняться параллельно. Исполнение операций 1 и 5 может быть отложено до моментов, показанных на диаграмме полыми полосками.

Рис. 1. Ресурсный критический путь

Ресурсный критический путь ” операции 3, 4 и 2, задержка исполнения которых приводит к задержке проекта в целом.

Поддержка корпоративных стандартов

Spider Project спроектирован таким образом, чтобы поддерживать корпоративные стандарты управления проектами. Для этого предусмотрена возможность создания непосредственно в пакете библиотек типовых фрагментов проектов, а также неограниченного количества всевозможных баз данных, включая производительности ресурсов на типовых назначениях, объемы и длительности типовых операций, расход материалов и расценки на единичных объемах типовых операций и назначений ресурсов и т. д. Пользователи могут создать (или импортировать из стандартных SQL баз, таких как Oracle, Access и т. д.) и любые другие базы данных и использовать их во всех проектах компании.

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

Анализ рисков и технология управления Spider Project

Опыт и анализ проектов показал, что детерминированные расписания имеют низкую (обычно 20 ” 35%) вероятность успешного исполнения. Отметим, что без анализа рисков нельзя обеспечить качественный анализ и управление проектами. Встроенные в Spider Project инструменты анализа рисков предназначены для определения реальных сроков и бюджетов проектов и позволяют определять и анализировать вероятность успешного исполнения директивных параметров проекта.

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

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

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

Ведение архивов проекта, анализ отклонений

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

Система учета

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

Особенности групповой работы

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

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

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

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

Отчетность

Spider Project поддерживает стандартные формы отчетности, имеющиеся в аналогичных программах, ” таблицы, сетевые и организационные диаграммы, диаграмма Гантта. Однако можно получить и дополнительные графические формы отчетности, в частности диаграмму Гантта для ресурсов проекта и Линейную диаграмму.

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

В Линейной диаграмме показывается продвижение проекта по метрике, которую определяет пользователь. Для линейно протяженных проектов (строительство трубопроводов, дорог и т. п.) в качестве метрики могут быть приняты километры трассы, для строительства зданий ” этажи, метрика может быть качественной (1-й этап, 2-й этап и т. д.).

В Линейной диаграмме по горизонтали откладывается метрика проекта, по вертикали ” время. На диаграмме разными цветами и видами линий отображаются работы различных типов в виде графиков, отображающих плановое состояние данного типа работ в различное время (например, в какое время на каком километре должны проводиться работы определенного типа). Получается очень компактное и наглядное отображение проекта ” на странице А4 можно отобразить ту же информацию, которая на диаграмме Гантта займет много листов формата А0.

Пример Линейной диаграммы (4-й поток строительства Каспийского трубопровода) представлен на рис. 2.

Рис. 2. Линейная диаграмма для некоторых работ строительства Каспийского трубопровода.

Характерная особенность Линейных диаграмм ” простой визуальный контроль непротиворечивости и полноты имеющейся информации.

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

Подробнее об особенностях пакета (в том числе тех, что из-за недостатка места не освещены в данной статье) и его стоимости можно узнать на сайте www.spiderproject.ru. Там же можно списать работающие демо-версии Spider Project Professional и Spider Project Lite, руководство по работе с пакетом, а также различные статьи и презентации на тему управления проектами. В форуме по управлению проектами на этом же сайте можно задать вопросы и получить необходимые консультации.

Функциональная архитектура

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

Spider Project Desktop ” версия, предназначенная для управления отдельными проектами. Не включает инструменты групповой работы над проектами, возможности расчета расписания работ с учетом ограничений на поставки материалов и финансирование проекта.

Spider Project Lite ” облегченная версия, предназначенная для управления проектами, в которых нет сложных назначений ресурсов. Не включает анализа рисков, возможностей работы с мультиресурсами и независимыми командами ресурсов, моделирования переменной загрузки ресурсов. Ограниченные возможности управления мультипроектами. Упрощенный учет.

Spider Project Viewer ” бесплатная версия, поставляемая вместе с рабочими программами и предназначенная для просмотра и анализа проектов руководством. Не поддерживает проведения расчетов.

Spider Project Demo ” версия с ограничением на максимальное количество операций проекта – до 40.

ИТ-архитектура

Операционные системы Windows 95/98/NT/2000

Собственная СУБД с возможностью импорта и экспорта всей информации в стандартные СУБД (Oracle, Access, Interbase и т. д.), Lotus Notes, MS Office, CSV.
Во всех версиях обеспечивается удаленный доступ к проектам с использованием FTP-сервера непосредственно из пакета. При этом обеспечивается доступ ко всем функциям – проекты открываются непосредственно с FTP-сервера и могут отправляться на FTP-сервер. Браузер не требуется.

Требования к ресурсам

Рекомендации по объему оперативной памяти для серверов и рабочих станций основаны на собственном опыте работы с проектами указанных размерностей:

• 10 000 операций – 64 Мбайт,
• 40 000 операций – 128 Мбайт,
• 80 000 операций – 256 Мбайт,
• 160 000 операций – 512 Мбайт.

При меньшем размере оперативной памяти замедляются расчеты, однако никаких иных отрицательных последствий не будет.

К объему дисковой памяти специальных требований не предъявляется – они зависят от объемов и количества ведущихся одновременно проектов.

Стоимость программного обеспечения

Spider Project Professional (долл.)

Spider Project Desktop

Spider Project Lite – 499 долл. независимо от числа рабочих мест

---

1. Термин “Иерархическая структура работ” ” перевод исходного термина Work Breakdown Structure. Отметим, что в литературе часто встречаются другие переводы этого термина ” “структура декомпозиции работ”, “структурная декомпозиция работ”. ” Прим. ред.
2. Операция ” элемент проекта, на исполнение которого назначаются ресурсы. В русской литературе иначе называется работой или задачей, англоязычный термин ” activity или task. Термин “операция” используется в России с середины 60-х годов в литературе по сетевому планированию, с 1992 года ” в пакете Spider Project. Мы этот термин предпочли другим, потому что элементами проекта могут быть такие “работы”, как поступление денег или набор прочности конструкции. ” Прим. авт.

Автор: Владимир Либерзон
Источник: Статья опубликована в журнале “Директор ИС”, #10, 2001 год

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

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

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

Для решения этих задач необходимо разработать компьютерную модель проекта, адекватно отражающую особенности его работ, ресурсов, технологических и временных ограничений [1-3]. На примере пакета Spider Project Professional рассмотрим, как решаются перечисленные задачи.

Разработка компьютерной модели проекта

Для создания компьютерной модели проекта в Spider Project необходимо проделать следующие шаги:

1. укрупненно описать проект, создав Иерархическую структуру работ (ИСР);
2. задать составляющие стоимости для финансового анализа и управления проектом;
3. составить перечень и характеристики операций (работ, задач) и ресурсов проекта;
4. задать взаимосвязи (ограничения на порядок исполнения) операций проекта и назначить ресурсы;
5. назначить стоимости на операции, ресурсы и назначения проекта;
6. задать ограничения на финансирование, поставки, сроки исполнения операций;
7. составить расписание исполнения работ проекта с учетом всех ограничений;
8. оптимизировать состав используемых ресурсов;
9. определить бюджет и распределение во времени плановых затрат проекта;
10. определить и смоделировать риски;
11. определить необходимые резервы на сроки, стоимости и потребности в материалах для исполнения запланированных показателей с заданной надежностью;
12. если заданы директивные сроки, стоимости, ограничения по поставкам, то определить вероятность их успешного соблюдения;
13. представить плановую информацию руководству и исполнителям.

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

Иерархическая структура работ проекта

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

Иерархические структуры работ позволяют получать отчетность по любым своим элементам. Таким образом, структура объектов позволяет подводить метрику «Итого» по объектам проекта, структура процессов — по процессам проекта, а структура ответственности — контролировать, как участники проекта справляются с работами в своих зонах ответственности. Spider Project позволяет завести в проекте теоретически неограниченное количество различных ИСР, в каждой из которых можно задавать требуемое число уровней иерархии.

Составляющие стоимости и операции

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

Характеристики операций проекта определяют показатели, которые в дальнейшем используются для моделирования проекта: длительность исполнения, объем работ на операции (особенность Spider Project), трудоемкость операции (ресурсо-часы, необходимые для ее исполнения), календарь операции, прямые затраты на операцию (по каждой составляющей затрат), тип операции (что является исходной информацией: длительность/трудоемкость или объем работ, или операция исполняется неопределенное время — от одного события до другого, или операция является вехой или контрольным событием, т. е. имеет нулевую длительность и определяет важные события проекта, например, завершение исполнения фаз), ограничения на сроки исполнения операции (например, начало не раньше определенной даты). Календарь операции используется как ограничение при составлении расписания исполнения работ проекта и определяет промежутки времени, когда можно исполнять операцию: только в дневное время, только летом и т.п. Основные типы операций: фиксированной длительностью; с фиксированным объемом (длительность — частное от деления объема на суммарную производительность назначенных ресурсов); гамак — такие операции длятся от выполнения связи на старт до выполнения связи на финиш (от события и до события); вехи или контрольные события — операции нулевой длины, обычно отражающие наступление важных событий проекта, таких как окончание фазы и т.п. Кроме того, можно задать, допускает ли операция прерывание своего исполнения, если, например, ресурсы, исполняющие операцию, требуются на других, более приоритетных работах, а также исполнять ее сразу, как только для этого сложатся условия (тип «как можно раньше»), или откладывать исполнение до тех пор, пока дальнейшая задержка не повлечет за собой нарушение каких-либо директивных сроков, либо задержит срок завершения проекта.

Ресурсы проекта

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

К основным характеристикам возобновляемых ресурсов относятся: общее количество, стоимость часа работы (по компонентам стоимости), потребление материалов за час работы, календари работы ресурсов, принадлежность к подразделению ИСР. В Spider Project можно наложить на ресурсы теоретически неограниченное количество иерархических структур, что позволяет группировать ресурсы произвольным образом и получать отчетность по загрузке ресурсов во всевозможных матричных структурах управления.

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

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

Взаимосвязи операций

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

• Финиш-Старт — следующая работа может начинаться после завершения предшествующей;
• Старт-Старт — следующая работа может начинаться после начала предшествующей;
• Финиш-Финиш — следующая работа завершается только после окончания предшествующей;
• Старт-Финиш — следующая работа может завершиться только после начала предшествующей.

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

Все перечисленные типы взаимосвязей являются связями типа «не раньше». Исполнение последующей операции всегда можно задержать без нарушения условия связи. Однако часто бывает, что следующую операцию необходимо начинать сразу по исполнению условия связи (самолет заправщик не может долго ждать тот самолет, который следует заправить, сложно укладывать трубу в траншею, выкопанную несколько месяцев назад, и т.п.). Поэтому в пакетах управления проектами можно задавать также так называемые жесткие связи, которые должны исполняться немедленно. Если заправляемый самолет будет позже, то и заправщик вылетит точно ко времени.

Назначение возобновляемых ресурсов и материалов

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

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

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

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

Поставки, финансирование и составление расписания

Моделирование поставок осуществляется путем задания отрицательного расхода соответствующих материалов на операциях, отображающих поставки. Для моделирования финансирования следует ввести составляющие стоимости, у которых стоимость единицы отрицательна, и назначить их на операции проекта, соответствующих поступлению финансов в проект. Задав финансирование и производство (поставки) материалов, можно получать отчеты не только по затратам и расходу материалов проекта, но и по cash flow и движению материалов, а также учитывать ограничения по финансированию и поставкам при составлении расписания исполнения работ проекта.

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

Моделирование проектов

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

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

Типовой фрагмент — компьютерная модель небольшой фазы, которая встречается в проектах и обычно составляется для некоторого типового объема работ, а при вставке типового фрагмента в проект, пользователь отвечает на запрос о реальном объеме фрагмента в конкретном проекте. В зависимости от ответа, характеристики модели автоматически корректируются. Примеры типовых фрагментов: строительство одного километра линейного участка трубопровода в равнинно-холмистой местности на грунтах 1-2-ой категории, получение разрешения в определенной инстанции и т.п.

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

Представления проекта

Рис.1. Диаграмма Гантта проекта выбора ПО

Данные компьютерного моделирования проектов могут быть представлены в разнообразных табличных и графических формах. На рис.1 представлена диаграмма Гантта проекта выбора программного обеспечения, отражающая не только сами работы проекта, но и назначения ресурсов.

Другие формы: сетевая диаграмма, организационные диаграммы — графические представления иерархических структур работ и ресурсов, гистограммы загрузки ресурсов, расхода материалов, диаграммы затрат, линейная диаграмма.

Рис.2. Линейная диаграмма строительства Каспийского трубопровода

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

Анализ рисков

Исследования показали, что вероятность успешной реализации проекта, параметры которого определены на базе того, как бывает обычно, колеблется в диапазоне 20-38%, поэтому учет рисков и неопределенностей имеет огромное значение на всех стадиях управления проектом.

В западных пакетах используется либо метод PERT, который не дает информации для построения управления на базе анализа рисков, либо имитационное моделирование (метод Монте-Карло) — простой и интуитивно понятный метод моделирования рисков, однако для получения достоверного статистического распределения результатов моделирования необходимо сделать столько проходов (испытаний), что моделирование реального проекта займет годы. Как же в западных пакетах решается эта проблема? При запуске имитационного моделирования пользователю предлагается задать устраивающее его число проходов модели. При этом по умолчанию предлагается заведомо недостаточное число, (например, пакет Open Plan предлагает сделать 10 проходов) — в реальных проектах число проходов должно исчисляться миллионами. При этом время просчета параметров проекта в каждом проходе может исчисляться минутами. В Spider Project мы отказались от моделирования по Монте-Карло и предлагаем упрощенный метод, который позволяет оценить распределение вероятности параметров, и, хотя точность оценки не высока, она мало отличается от точности, достижимой при разумном применении метода Монте-Карло.

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

Рис.3. Целевое расписание исполнения проекта выбора программного обеспечения, составленное для обеспечения 70% вероятности успешного соблюдения запланированных сроков

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

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

Обычные клиент-серверные технологии не вполне приспособлены к особенностям проектного управления, а потому в Spider Project была разработана другая технология групповой работы.

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

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

Учет и анализ исполнения

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

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

Рис.4. Тренды вероятностей успеха проекта выбора ПО

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

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

Заключение

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

Литература

[1] Директор информационной службы (CIO), 2001, № 4. Выпуск посвящен программам управления проектами

[2] Виктор Терехин. Какой С.У.П. вам нужен. Потребитель. Компьютеры и программы, 2002, № 6, раздел Экспертиза и тесты

[3] A Guide to the Project Management Body of Knowledge, 2000 Edition, Project Management Institute

Владимир Либерзон (spider@mail.cnt.ru) — генеральный директор компании «Технологии управления Спайдер» (Москва)

---

Пакет Spider Project

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

Тестирование западных пакетов показало, что в области оптимизации расписания исполнения проекта при ограниченных ресурсах российские разработчики действительно впереди — далее простого ручного выбора приоритетов при назначении ресурсов среди полей операций ни один из западных пакетов не пошел. Более того, сама технология моделирования работы ресурсов была достаточно примитивной и не позволяла использовать приемы планирования, которыми мы уже активно пользовались. Наш небольшой коллектив программистов разработал программу, рассчитывающую расписание исполнения проекта с учетом ресурсных ограничений, которое, как правило, было более коротким, чем расписания для тех же проектов, составленные западными пакетами. Однако у нас не было сил и средств, чтобы довести систему до товарного вида. К тому же Управление Проектами в то время было в России непонятным словосочетанием, а потому разработанный нами модуль был англоязычным. С этим модулем в 1990 году мы направились в Лондон искать партнеров среди поставщиков программ управления проектами, однако не получили иных предложений, кроме желания купить разработанные алгоритмы. Как нам объяснили в компании K&H (впоследствии она была куплена Artemis), производители программ управления проектами не могли быть заинтересованы в разработке еще одной конкурирующей программы, а вывод новой программы на рынок обойдется примерно в 1 млн. фунтов.

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

---

Технология управления Spider

Spider Project составляет несколько расписаний: оптимистическое, наиболее вероятное, пессимистическое и целевое расписания исполнения проекта — возникает вопрос, какие расписания использовать? Для определения контрактных сроков предлагается использовать целевое расписание, а для заданий исполнителям — оптимистическое. Действительно, представьте себе, что вам дали пять дней на работу, которую вы способны исполнить за три. Практически всегда тот, кто получает такое задание, первые два дня будет заниматься другими делами, а за исполнение задания возьмется за три дня до срока его сдачи. Но дали вам пять дней именно потому, что знают, что вам не дадут спокойно работать эти три дня, будут возникать проблемы, из-за которых работа будет задерживаться и займет пять дней. Эти проблемы никуда не денутся и в результате работа займет семь дней вместо пяти — резервы, которые даются исполнителям, как правило, расходуются впустую.

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

На рынке программных средств управления проектами в России наряду с известными зарубежными пакетами, такими как Microsoft Project, Open Plan, Suretrak, Primavera Project Planner присутствует и Российский пакет Spider Project. В России этот пакет наиболее популярен и используется крупнейшими корпорациями для управления самыми престижными проектами. У пакета Spider Project много отличий от своих зарубежных аналогов, которые делают его привлекательным для Российских потребителей.

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

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

Структура данных Spider Project

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

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

Операции в Spider Project

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

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

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

Ресурсы в Spider Project

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

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

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

Календари в Spider Project

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

Назначения в Spider Project

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

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

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

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

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

Стоимости

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

Центры

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

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

Иерархические структуры в Spider Project

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

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

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

Архивы в Spider Project

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

Вычисления

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

• разработку расписания исполнения проекта без учета ограниченности ресурсов
• разработку расписания исполнения проекта с учетом ограниченности ресурсов (leveling)
• определение критического пути и резервов времени исполнения операций проекта
• определение потребности проекта в финансировании, материалах и оборудовании в любые периоды времени
• определение распределения во времени загрузки возобновляемых ресурсов
• анализ рисков и планирование расписания и других характеристик проекта с учетом рисков
• ведение учета исполнения
• анализ отклонений хода работ от запланированного (в том числе Earned Value Analysis) и прогнозирование основных параметров проекта

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

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

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

В большинстве реальных проектов расписания Spider Project существенно короче расписаний, составляемых другими пакетами при тех же ограничениях на ресурсы проекта. Не менее важной является и устойчивость расписания, особенно на фазе исполнения. В процессе исполнения оставшиеся плановые длительности операций меняются, поэтому и расписания, составленные пакетами в автоматическом режиме могут оказаться совершенно другими. Изменение длительности операции на один день влечет за собой изменение планового срока завершения проекта на три недели в ту или другую сторону! Новое расписание будет оптимальным, соответствующим расписанию Spider Project, однако встает вопрос — а что, если вы уже заключили контракты, запланировали поставки и т.д.? С этого момента вы не сможете использовать автоматический расчет расписания проекта, если только вы не пересмотрите свои соглашения. Именно поэтому в пакете Spider Project имеется дополнительная опция — поддержка расписания предыдущей версии проекта, в качестве которой вы можете выбрать любую версию из архива проекта.

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

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

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

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

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

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

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

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

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

Анализ рисков и планирование с учетом рисков

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

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

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

Анализ отклонений хода работ от запланированного

Как уже упоминалось, ведение архивов проекта, в том числе архивов учета, позволяет анализировать отклонения хода реализации проекта не только по сравнению с базовой версией, но и по сравнению с версией прошлой недели, прошлого месяца и т.д. Архивы учета позволяют анализировать работу ресурсов и корректировать их плановую производительность. Наличие архивов позволяет отслеживать тенденции и прогнозировать будущие параметры, в том числе определить коэффициент исполнения, используемый в Earned Value Analysis. Что касается Earned Value Analysis мы считаем полезной возможность его проведения не только для итоговых затрат, но и для отдельных стоимостных составляющих и стоимостных центров.

Базы данных

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

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

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

Очень важным инструментом для создания корпоративной культуры и корпоративных стандартов управления проектами является библиотека типовых фрагментов. Типовой фрагмент — это небольшой проект, определяющий технологию выполнения типового участка работ определенного объема. Этот проект включает все необходимое для включения его в состав ведущихся в компании проектов — и материалы, и ресурсы, и стоимостные составляющие. Библиотека фрагментов разрабатывается и поддерживается в Центре управления проектами компании (Project Office).

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

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

Интересным побочным эффектом использования библиотек типовых фрагментов является технология формирования иерархической структуры работ не сверху вниз, как обычно, а снизу вверх. В такой структуре типовые фрагменты служат пакетами работ. Поскольку мы обычно используем несколько структур в одном проекте, то технологии снизу вверх и сверху вниз используются параллельно и взаимно дополняют друг друга. 5. Отчеты Наряду со стандартными графическими отчетами — диаграммой Гантта, сетевой диаграммой, диаграммами загрузки ресурсов, расхода материалов и графиками затрат по проекту и отдельным фазам, Spider Project предлагает пользователям Ресурсную диаграмму Ганта и Линейную диаграмму, которые будут описаны далее.

Ресурсная диаграмма Ганта

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

Гистограммы загрузки ресурсов

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

Линейная диаграмма

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

Заключение

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

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

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

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

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

Владимир Либерзон, Игорь Лобанов

Просмотры: 10 638

Введение
и создание проекта в Spider
Project.

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

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

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

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

На
рынке программных средств управления
проектами в России наряду с известными
зарубежными пакетами, такими как
MicrosoftProject, OpenPlan, Suretrak, PrimaveraProjectPlanner
присутствует и Российский пакет
SpiderProject. В России этот пакет наиболее
популярен и используется крупнейшими
корпорациями для управления самыми
престижными проектами. У пакета
SpiderProject много отличий от своих зарубежных
аналогов, которые делают его привлекательным
для Российских потребителей. Это связано
и с принятой в России технологией
управления проектами, которая отличается
от той, которая лежит в основе зарубежных
пакетов. И с тем вниманием, которое в
России традиционно уделяется оптимизации
использования ресурсов и адекватности
математических моделей объектов.

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

1. Создание иерархической структуры проекта

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

1.1 Определение фаз

Как
правило, создание компьютерной модели
проекта начинается с разработки его
Иерархической
структуры работ (ИСР).Иерархическая
структура
работ позволяет произвести декомпозицию
работ проекта на более мелкие, обозримые
и управляемые части, точнее определить
и состав и характеристики работ, которые
предстоит выполнить.

1.2 Определение операций

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

—
На операции можно назначить определенных
исполнителей, которые заняты на ней от
начала и до конца,

—
Продолжительность исполнения операций
сопоставима с периодом учета исполнения,

—
На операции можно назначить стоимость
и расход материалов.

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

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

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

Операция
в программе может быть четырех типов:

Операция
типа «Длительность»
– длительность является исходной
информацией при включении операции в
расписание и не зависит от назначенных
ресурсов.

Операция
типа «Производительность»
– исходной информацией для операции
являются ее объем и производительность
назначений. При этом длительность
операции вычисляется в процессе
составления расписания исполнения
работ проекта.

Операция
типа «Гамак»
– операция, которая длится от одного
события до другого. Длительность гамака
определяется моментом выполнения всех
условий на ее начало и моментом выполнения
всех условий на окончание операции.
Условия на начало и конец операции типа
гамак задаются через связи, идущие к
началу и концу операции и директивные
даты (Старт НРЧ и Финиш НПЧ).

Операция
типа «Контрольное событие»
– операция нулевой длительности. Служит
для обозначения события, существенного
для контроля исполнения проекта.

Приоритет
операции – число,
определяющее порядок выполнения операций
в случае ресурсных ограничений при
расчете расписания с выравниванием
ресурсов.

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

Операции
проекта

Таблица
1.

Код	Название	Тип ДПГ	Объём	Единица объёма
1	Срезка растительного слоя грунта с перемещением до 10 м бульдозерами мощностью: 79 кВт (108 л.с.), группа грунтов 2	Длительность	960	m3
2	Разработка грунта с погрузкой на автомобили-самосвалы экскаваторами с ковшом вместимостью: 0,65 (0,5-1) м3, группа грунтов 2	Длительность	4500	m3
3	Разработка грунта с перемещением до 10 м бульдозерами мощностью: 59 кВт (80 л.с.), группа грунтов 2	Длительность	4500	m3
4	Уплотнение грунта пневматическими трамбовками, группа грунтов: 1-2	Длительность	26,1	m3
5	Планировка площадей: ручным способом, группа грунтов 2	Длительность	26,1	m2
8	Установка каркасов и сеток: в стенах массой одного элемента до 20 кг	Длительность	7,83	т
9	Устройство железобетонных фундаментов общего назначения под колонны объемом: до 3 м3	Длительность	103	m3
10	Монтаж и демонтаж объемно-переставной («туннельной») опалубки бетонных конструкций: перекрытий	Длительность	311,6	m2
11	Укладка балок фундаментных длиной : до 6 м	Длительность	20	шт
12	Укладка блоков и плит ленточных фундаментов при глубине котлована до 4 м, масса конструкций: до 1,5 т	Длительность	170	шт
13	Укладка блоков ленточных фундаментов при глубине котлована до 4 м, масса конструкций: до 1,5 т	Длительность	820	шт
14	Гидроизоляция боковая обмазочная битумная в 2 слоя по выровненной поверхности бутовой кладки, кирпичу, бетону	Длительность	302	m2
15	Гидроизоляция стен, фундаментов: горизонтальная оклеечная в 2 слоя	Длительность	517	m2
16	Кладка стен кирпичных наружных: простых при высоте этажа до 4 м	Длительность	240,08	m3
17	Кладка перегородок из кирпича: армированных толщиной в 1/4 кирпича при высоте этажа до 4 м	Длительность	2990	m2
18	Установка маршей-площадок массой более 1 т	Длительность	8	шт
19	Установка панелей перекрытий с опиранием: на 2 стороны площадью до 10 м2	Длительность	48	шт
20	Установка панелей покрытия с опиранием: на 2 стороны площадью до 10 м2	Длительность	80	шт
21	Устройство пароизоляции: оклеечной в один слой	Длительность	720	m2
22	Утепление покрытий плитами: из минеральной ваты или перлита на битумной мастике в один слой	Длительность	720	m2
23	Устройство выравнивающих стяжек: цементно-песчаных толщиной 15 мм	Длительность	720	m2
24	Устройство кровель плоских четырехслойных из рулонных кровельных материалов на битумной мастике: с защитным слоем из гравия на битумной антисептированной мастике	Длительность	720	m2
25	Установка в жилых и общественных зданиях блоков оконных с переплетами: спаренными в стенах каменных площадью проема более 2 м2	Длительность	150	m2
26	Установка блоков в наружных и внутренних дверных проемах: в каменных стенах, площадь проема более 3 м2	Длительность	166	m2
27	Устройство вентилируемых фасадов с облицовкой панелями из композитных материалов: с устройством теплоизоляционного слоя	Длительность	1365	m2
28	Штукатурка поверхностей внутри здания известковым раствором улучшенная: по камню и бетону стен	Длительность	2930	m2
29	Окраска поливинилацетатными водоэмульсионными составами улучшенная: по штукатурке стен	Длительность	4080	m2
30	Устройство стяжек: цементных толщиной 20 мм	Длительность	2840	m2
31	Устройство покрытий: из линолеума на клее«Бустилат»	Длительность	2840	m2
32	Устройство подстилающих слоев: песчаных	Длительность	86,4	m3
33	Устройство гидроизоляции обмазочной: в один слой толщиной 2 мм	Длительность	86,4	m2
34	Устройство стяжек: цементных толщиной 20 мм	Длительность	86,4	m2
35	Устройство полов бетонных толщиной : 100 мм	Длительность	86,4	m2
6	Устройство бетонной подготовки	Длительность	100
7	Монтаж и демонтаж объемно-переставной («туннельной») опалубки бетонных конструкций: перекрытий	Длительность	100

В
данной таблице приведены те операции,
которые будут использоваться при
строительстве офисного здания. Эту
таблицу мы набираем в SpiderProject.
В ней указываются код, наименование
операции, объем (плановый), единицу
объема и тип ДПГ.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #