Исследование эффективности внедрения технологии применения автоматизации процесса управления строительными проектами с помощью программного пакета Spider Project

Введение

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

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

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

Ресурсы

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

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

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

Календари

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

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

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

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

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

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

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

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

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

Базовые функциональные возможности системы календарного планирования

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

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

Назначения

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

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

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

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

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

Стоимости

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

Центры

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

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

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

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

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

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

Архивы

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

ВЫЧИСЛЕНИЯ

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

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

Размещено на http://www.allbest.ru/

8

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

определение критического пути и резервов времени исполнения операцРазмещено на http://www.allbest.ru/

8

ий проекта

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

определение распределения во времени загрузки возоРазмещено на http://www.allbest.ru/

8

бновляемых ресурсов

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

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

Размещено на http://www.allbest.ru/

8

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

Размещено на http://www.allbest.ru/

8

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

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

В большинстве пакетов под расписанием с учетом ограниченности ресурсов понимается расписание, в котором учитывается ограниченность возобновляемых ресурсов. При этом традиционно используются самые простые эвристики, которые не обеспечивают ни получения расписания, близкого к оптимальному, ни устойчивости этого расписания. В лучшем случае пользователям предоставляется возможность выбора критериев при назначении ресурсов в процессе составления расписания, что позволяет выполнить перебор и выбрать лучшее из полученных решений. Однако и такой перебор не обеспечивает получения приемлемых результатов. В 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 предлагает пользователям Ресурсную диаграмму Ганта и Линейную диаграмму, которые будут описаны далее.

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

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

Диаграммма Гамнта (англ. Gantt chart, также ленточная диаграмма, график Ганта) -- это популярный тип столбчатых диаграмм (гистограмм), который используется для иллюстрации плана, графика работ по какому-либо проекту. Является одним из методов планирования проектов. Используется в приложениях по управлению проектами.

Первый формат диаграммы был разработан Генри Л. Гантом в 1910 году.

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

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

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

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

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

Во многих представлениях, включая представление «Использование ресурсов», ресурсы с превышением доступности показаны красным цветом. Превышение доступности имеет место всегда, когда максимальное число единиц (Максимальное число единиц. Максимальный процент или количество единиц, которые можно запланировать для ресурса на выполнение любых задач. Значение максимального количества указывает максимальную возможность использования ресурса для работы. Значение по умолчанию 100%.) ресурса на какое-то время оказывается выше заданного значения. В листах ресурсов поле индикаторов (Поле индикаторов. Поле, содержащее графический индикатор, представляющий сведения о назначении, ресурсе или задаче. Например, индикатор в виде галочки показывает, что задача завершена.) для ресурсов с превышением доступности включает в себя также индикатор (Индикаторы. Небольшие значки, которые представляют сведения о задаче или ресурсе, отображающиеся в поле «Индикаторы». Поле «Индикаторы» расположено справа от поля «Идентификатор» и отображается во многих таблицах.) выравнивания ресурса , который указывает на необходимость выравнивания (Выравнивание. Устранение конфликтов ресурсов или превышения доступности ресурсов, осуществляемое в результате задержки или разделения определенных задач. Когда Project выполняет выравнивание загрузки ресурсов, выбранные назначения ресурса распределяются и перепланируются.). Чтобы оценить, является ли превышение доступности ресурса допустимым, следует проверять наличие этого индикатора и просматривать назначения задач.

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

Примечание. В представлении «Использование ресурсов» отображаются не только назначения ресурсов задачам в рамках текущего проекта, но и суммарные назначения ресурсов. Суммарное назначение ресурса показывает полный объем трудозатрат, назначенный данному ресурсу во всех проектах. Суммарное назначение ресурса отображается только при наличии соединения с Microsoft Office Project Server и действующего корпоративного проекта (Корпоративный проект. Проект, хранимый на сервере Project Server для обеспечения целостности информации. Чтобы внести изменения в корпоративный проект, пользователь с соответствующими правами доступа должен извлечь проект с сервера Project Server и после изменения вернуть обратно на сервер.). Если не требуется, чтобы строки суммарных назначений влияли на итоги, показываемые в представлении «Использование ресурсов», выберите эти строки и нажмите клавишу DEL.

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

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

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

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

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

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

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

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

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

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