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

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

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

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

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

Организация исходной информации

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

Операции

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

Длительность исполнения,

Объем работ на операции (особенность Spider Project),

Трудоемкость операции (ресурсо-часы, необходимые для ее исполнения),

Календарь операции,

Прямые затраты на операцию (по каждой составляющей затрат),

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

Ограничения на сроки исполнения операции (например, начало не раньше определенной даты).

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

Основные типы операций:

с фиксированной длительностью,

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

гамак – такие операции длятся от выполнения связи на старт до выполнения связи на финиш, то есть от события и до события,

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

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

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

У большинства операций длительность зависит от назначенных ресурсов. У таких операций обычно задается объем работ (в частном случае трудоемкость) и производительности назначенных ресурсов. В Спайдере это операции типа Производительность.

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

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

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

следует ли операцию исполнять как можно раньше или как можно позже,

можно ли прерывать исполнение начатой операции, если ресурсы понадобились на более приоритетной работе, o является ли операция масштабируемой, то есть имеется ли пропорциональность длительности и объема работ операции и объема того пакета работ, к которому она принадлежит.

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

Взаимосвязи

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

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

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

Ресурсы

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

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

К основным характеристикам возобновляемых ресурсов относятся:

общее количество,

стоимость часа работы (по компонентам стоимости),

потребление материалов за час работы,

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

принадлежность к подразделению Иерархической Структуры Ресурсов.

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

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

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

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

К основным характеристикам назначений относятся

количество назначенных ресурсов,

производительности назначенных ресурсов,

процентная загрузка ресурса на работе (доля рабочего времени в процентах, которая расходуется на этой операции),

потребление материалов на назначении (фиксированное или за час работы ресурса),

стоимость назначения (фиксированная или за час работы ресурса).

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

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

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

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

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

В Spider Project можно также задать мультиресурсы.

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

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

Календари

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

Назначения ресурсов

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

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

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

Кроме того, в Спайдере можно задавать переменную загрузку ресурсов на назначении. Например, задать, что на работе можно использовать от трех до пяти единиц ресурса с загрузкой от 50 до 70 процентов. Тогда пакет будет знать, что работа может начинаться, если можно назначить на ее исполнение не менее трех единиц ресурса, свободных не менее половины своего рабочего времени. Если в дальнейшем появятся дополнительные свободные единицы ресурса, то их можно назначить на исполнение работы (но не более пяти единиц). Работа может потреблять до 70% рабочего времени назначенных ресурсов. При появлении более приоритетных работ, ресурсы могут перебрасываться на их исполнение операции и возвращаться обратно по мере освобождения. При этом, если операция не допускает прерывания, то минимальное количество ресурсов на операции и их минимальная загрузка (в нашем примере 3 единицы ресурса и загрузка 50%) не нарушаются. Длительность операции рассчитывается в соответствии с использованием ресурсов.

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

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

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

Назначения стоимостей

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

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

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

Таблица 1. Возможности назначения стоимостей в пакете Спайдер Проджект.

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

Структуры

В Спайдер Проджект можно создавать сколько угодно Иерархических Структур Работ и Ресурсов. Мы рекомендуем использовать в одном проекте несколько параллельных структур работ - структуры, организованной по иерархии результатов проекта, структуры, организованной по процессам проекта, структур ответственности, которые могут включать упоминающиеся в PMBOK Guide® Организационную Структур Проекта и Иерархическую Структуру Контрактов. Переключаясь между структурами, можно взглянуть на проекты с разных сторон, получать различные виды отчетов.

Корпоративные стандарты

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

Корпоративные справочники

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

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

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

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

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

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

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

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

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

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

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

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

В Спайдере есть несколько уровней оптимизации при составлении расписания проекта:

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

• Следующий уровень - продвинутый. Программа использует критерий, предложенный пользователем, как отправную точку, но пытается решение улучшить. Улучшение возможно, но ограничено определенными рамками, потому не всегда предлагаемое решение оптимально.

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

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

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

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

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

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

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

Ресурсный критический путь (Критическая Цепь)

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

Ресурсно критические операции - это такие, задержка исполнения которых приводит к задержке срока завершения проекта при имеющихся ресурсных ограничениях. Ресурсный критический путь состоит из ресурсно критических операций, образующих самую длительную цепочку от начала и до завершения проекта. Спайдер Проджект вычисляет ресурсно критический путь с момента вывода на рынок в 1993 году. В 1997 году вышла книга Голдратта Критическая Цепь, быстро набравшая популярность. В этой книге на популярном уровне излагались подходы, давно реализованные в Спайдере, однако не предлагались алгоритмы расчета Критической цепи. В результате теория до сих пор остается не столько количественной, сколько качественной. Тем не менее она завоевала признание, набирает популярность и уже упоминается в PMBOK Guide®. Ряд зарубежных пользователей Спайдера был привлечен именно тем, что в нем поддерживаются все методы теории критической цепи, но на более совершенном уровне.

Давайте рассмотрим пример проекта, в котором ресурсы ограничены и посмотрим, как рассчитывают критические работы и временные резервы операций разные пакеты и что такое ресурсно критические операции и ресурсный критический путь.

Проект RCP состоит из пяти операций. На первую и третью назначен ресурс А, на вторую и четвертую - ресурс В, пятая операция - контрольное событие Завершение проекта. Первая операция предшествует второй, третья - четвертой, а пятая операция следует и за второй, и за четвертой. Длительности первой и второй операции по 10 дней, третьей - 1 день, четвертой - 9 дней. Имеется лишь по одной единице каждого ресурса.

Если этот проект рассчитать в MS Project, то длительность проекта составит 29 рабочих дней, а резервы (Total Slack) будут посчитаны неверно. Как видно на рис. 1, пакет покажет наличие резервов у операций, задержка которых приводит к задержке завершения проекта, и, наоборот, отсутствие резерва у операции 3, которую в расписании MS Project можно безболезненно отодвинуть на 9 дней.

Рис.1. Расписание проекта RCP, составленное пакетом MS Project

По умолчанию такое же расписание как и MS Project составит и Primavera Project Management, однако с другими значениями полных резервов (Total Float) операций, но тоже неверных. Пакет показывает, что даже завершающая (!) операция проекта имеет десятидневный резерв.

Однако в отличие от Microsoft Project, в Primavera Project Management можно подобрать такой критерий назначения ресурсов, который позволит улучшить первоначальное расписание:

Рис.3. Расписание проекта RCP, составленное пакетом Primavera Project Management по критерию «Оставшаяся длительность».

Однако и во втором случае полные резервы операций рассчитываются неверно (откладывая исполнение операции 4 более, чем на один день, придется отложить и исполнение операции 2, а значит задержать срок завершения проекта, а операцию 3 вообще нельзя задерживать).

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

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

На рис.4 представлено расписание, составленное Спайдером, с правильными значениями резервов работ.

Ресурсный критический путь (критическая цепь) состоит из операций 3, 1, 2 и 5. Задержка любой из этих операций означает задержку срока завершения проекта. И лишь у операции 4 есть резерв в один рабочий день.

Критерии успеха проекта

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

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

Итак, делаются следующие шаги:

1. Определяется тот момент в будущем, который будет использоваться для оценки бизнес результата проекта (целевой момент).

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

3. Если такая оценка затруднительна, то назначаются стоимости рабочего дня при опоздании и, наоборот, при опережении планового срока завершения проекта (они могут быть разными). Эта стоимость может определяться

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

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

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

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

Рис.5. Укрупненное расписание проекта, составленное без учета финансовых ограничений.

На рис.5 вы можете увидеть расписание проекта, составленное без учета возможностей финансирования. Из диаграммы потока денежной наличности видно, что в некоторую целевую дату ожидаемая прибыль достигнет 525863 единиц. Однако из диаграммы движения средств в проекте видно, что имеются периоды исполнения проекта, не обеспеченные финансированием.

Если рассчитать этот же проект с учетом ограничений по финансированию, то ожидаемая прибыль снизится до 480673 единиц, т.е. примерно на 45000 единиц, как видно на рис.6.

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

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

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

В пакете Спайдер Проджект можно создавать неограниченное количество версий проекта и сравнивать любые две версии между собой.

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

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

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

Рис.7. Тренды показателей строительного проекта

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

Таблица 2. Оценки трендов показателей строительного проекта.

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

Базовое расписание, с которым производилось сравнение, на диаграмме Ганта представлено серым.

Анализ освоенных объемов в Спайдер Проджект

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

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

Рис.8. Тренды показателей освоенного объема строительного проекта.

Анализируя тренды, можно определить, когда возникали проблемы, когда удавалось с ними справиться, каков текущий прогноз покзателей освоенного объема на будущие периоды.

Моделирование рисков

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

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

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

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

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

Метод трех сценариев

Согласно этому подходу создаются три сценария реализации проекта: Спайдер Проджект - особенности и технологии

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

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

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

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

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

Буферы и планы

Итак, на стадии планирования создаются три версии проекта и на базе этих версий можно определить директивные показатели, достижение которых имеет разумную вероятность (обычно 70 - 80%). Эти показатели находятся вне расписаний. Опыт показывает, что вероятность выполнения расписания, основанного на вероятных оценках, обычно находится в диапазоне 25 - 35%, потому директивные сроки и бюджеты находятся где-то между вероятными и пессимистическими сроками и бюджетами. Вопрос в том, какие расписания использовать для управления.

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

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

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

Таким образом, в таком проекте необходимо сравнивать план и исполнение с этими четырьмя бюджетами и контролировать вероятности их выполнения. Это подразумевает необходимость задания различных директивных оценок для стоимости тех же самых работ. Так, например, возможно задание целевого бюджета для команды с вероятностью выполнения 70%, целевого бюджета руководства с начальной вероятностью выполнения 90%, контрактного бюджета со 95% вероятностью выполнения при учете только известных рисков. В процессе исполнения нужно будет контролировать, что происходит с вероятностью выполнения каждого из этих бюджетов.

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

Анализ исполнения в Spider Project рекомендуется вести тремя основными способами:

1) Анализ освоенных объемов,

2) Анализ трендов вероятности успеха,

3) Анализ ресурсов.

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

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

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

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

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

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

Управление портфелем проектов

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

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

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

Организация учета и групповой работы с проектом

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

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

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

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

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

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

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

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

Взаимодействие с другими программами

При разработке Спайдера была изначально поставлена задача разработать систему, минимально зависящую от других программ. Единственная программа, которая нужна для того, чтобы работал Спайдер Проджект - это любая версия Windows, начиная с Windows'98. Программа использует собственную базу данных, собственную систему хранения информации и т.д. Однако существуют развитые возможности работы с внешними программами. Любая таблица Спайдера может быть отправлена в Excel или текст в формате CSV, который является стандартом для обмена данными между различными программами. Проекты могут сохраняться и открываться из стандартных баз данных, таких как SQL Server или Oracle. Спайдер может импортировать проекты из MS Project и Primavera Project Management, а также экспортировать свои проекты в эти программы. Однако при этом пропадет целый ряд полезной информации из-за отсутствия в других программах соответствующих полей - это относится к объемам работ и производительностям ресурсов, различным характеристикам назначений ресурсов (например, сдельной оплате работ), составляющим стоимости, дополнительным иерархическим структурам работ, мультиресурсам и ролям, центрам стоимостей, ресурсов и материалов и т.д. Однако данные при этом преобразуются таким образом, чтобы итоговые показатели не изменились - экспортируется общая стоимость, стоимости назначений преобразуются в стоимости операций, операции, у которых исходной информацией является объем работ и производительность ресурсов, преобразуются в операции типа длительность. Проблемой остается экспорт назначений с переменной загрузкой или количеством назначенных ресурсов - когда загрузка или количество назначенных ресурсов на операции меняется на протяжении ее исполнения. Не переносится и моделирование сменной работы, а также независимые назначения команд, когда ресурсы работают на операциях независимо друг от друга. Мы рекомендуем избегать использования переменной загрузки ресурсов и моделирование сменной работы при необходимости экспорта моделей в другие программы управления проектами.

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

Форматы экспорта и импорта проектов в текстовые файлы и реляционные базы данных открыты и пользователи Спайдер Проджект успешно связывают Спайдер с другими программами самостоятельно. Так, у ряда пользователей Спайдер работает с восьмой версией 1С, а в Гонконге специалисты из Tecton Ltd связали Спайдер с Автокадом и используют для трехмерного моделирования строительства высотных зданий.

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

Отчеты Спайдер Проджект

Спайдер Проджект создает самые разнообразные табличные и графические отчеты. К графическим отчетам относятся диаграммы Гантта для проектов, операций, ресурсов, сетевая диаграмма, гистограммы использования и загрузки ресурсов, графики затрат и движения денег и материалов, графические отчеты по анализу освоенных объемов, тренды отклонений и вероятности успеха проекта. Особого упоминания заслуживает Линейная Диаграмма которую на Западе называют Line of Balance.

На этой диаграмме по горизонтали (оси X) откладывается некоторая метрика проекта. Для трубопровода это могут быть километры трассы, для высотного здания - этажи, но метрика может быть и качественной - например, этапы. На оси Y откладывается время. Различные виды работ отображаются линиями разного цвета и толщины, которые выбираются пользователем. На такой диаграмме можно легко увидеть какие работыи когда будут проводиться в любом месте метрики проекта. Это очень компактное и удобное отображение плана, а при вводе учета, наглядное отображение имеющихся отклонений. Линейная диаграмма строительства участка трубопровода представлена на рис.9.

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