3.Программы в проекте: плюсы минусы

3. Проекты: программирование, названия программ. Их плюсы и мин использования каждой программы

Информационная система управления проектами

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

Информационные технологии в УП

Существует 2 большие группы программных продуктов

1) Расчет, финансово-экономическое моделирование, подготовка бизнес-планов

• Microsoft Office Excel

• Альт - Инвест www.alt-invest.ru - фин и инвестиц анализ

• ProjectExpertwww.expert–systems.ru - программа разработки бизнес-плана и оценки инвестиционных проектов + оценка рисков, стоимости, чувствительности, безубыточности

• Prime Expert

2) Управление сроками, ресурсами, стоимостью проекта, отслеживание хода выполнения

• Primavera (ПМСОФТ) www.pmsoft.ru

• Spider Project (Спайдер) www.spiderproject.ru

• Microsoft Project (Майкрософт) www.microsoftproject.com

• Другие: Advanta, Open Plan, Artemis, AvicomProjectmate, 1C PMO

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

Требования к языку. Из перечисленных пакетов русифицированы Spider Project, SureTrak и Time Line 1.0 - старая версия Time Line, которую можно использовать для учебных целей. Недавно выпущена русская версия пакета Open Plan. Пакет Artemis Schedule Publisher локализован частично. У пакета русское меню и диалоги, но зато англоязычная помощь. Переведен на русский язык User Guide (обзор основных функций), но остался англоязычным Manual (основной учебник). Это создает серьезные трудности в практической работе с пакетом. Обнаружив в англоязычной помощи ссылку на какой-либо пункт меню приходится догадываться как это переведено на русский язык. Так что работа с пакетом требует некоторой лингвистической сноровки. Остальные пакеты и в том числе современные версии Time Line - первого из американских пакетов, появившихся на русском языке, не планируются к локализации в ближайшем будущем. Вы должны решить, насколько для вашей организации существенна возможность работы на русском языке.

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

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

Требования к типам ресурсов. Дешевые пакеты не в полной мере позволяют планировать и учитывать расход материалов (невозобновляемых ресурсов). Не все пакеты (только CA-SuperProject, Spider Project и Artemis) позволяют моделировать производство материалов. Если в ваших проектах материалы производятся на одних работах и расходуются на других, либо вы хотите моделировать поставки, то это для вас серьезное ограничение в выборе пакета.

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

У вас могут возникнуть и другие требования к описанию назначений. Большинство перечисленных требований выполняется лишь в пакете Spider Project (1, 2, 4, 6).

Требования к календарям. Не все пакеты позволяют использовать кроме календарей ресурсов и календари работ.

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

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

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

В частности, ни один из Западных пакетов не смог составить разумного расписания проекта "ПОКУПКА" - по планам, составленным Западными пакетами, проект должен занять на три недели больше времени, то есть длительность работ при тех же ресурсах возрастает на 25%.

Кроме того, Spider Project позволяет при планировании определить резервы сроков исполнения работ, которые можно использовать при управлении в отличие от резервов, определяемых Западными пакетами. Дело в том, что Spider Project каждый раз составляет два различных расписания выполнения работ проекта - одно в режиме Как Можно Раньше (КМР), а другое - Как Можно Позже (КМП). Во втором расписании сроки исполнения работ отодвигаются до тех пор, пока дальнейшая задержка не приведет к нарушению каких-либо директивных сроков, либо срока завершения проекта по расписанию КМР. Оба расписания составляются при одинаковом составе ресурсов проекта. Резерв по Spider Project - это промежуток времени между началами работ в этих двух расписаниях. Западные же пакеты под полным резервом (Total Float) понимают промежуток времени между началом работ в расписании, составленном с учетом ограниченности имеющихся ресурсов, и началом работы в расписании с тем же сроком завершения, но без учета ограниченности ресурсов проекта. Использование такого резерва практически неизбежно ведет к нарушению сроков выполнения работ.

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

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

Требования к учету и контролю хода работ. Для большинства пакетов (кроме Spider Project) перечисленные требования могут быть выполнены лишь с использованием внешних программ. В Spider Project предусмотрены средства для автоматизированного учета перечисленных факторов внутри пакета. Большинство пакетов позволяет хранить и сравнивать лишь текущий и базовый план. Лишь Spider Project и Artemis Project View позволяют вести архивы изменений и сравнивать между собой до 99 версий текущего проекта.

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

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

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