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

Требования к типам работ:

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

2)      фиктивность (работы нулевой длительности), отражающие наступление тех или иных событий, причем эти фиктивные работы могут требовать определенных ресурсов;

3)      условная длительность, определяемая длительностью других работ.

 

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

Требования к типам ресурсов. Ресурсы могут быть:

     возобновляемыми;

     расходуемыми;

     производимыми.

 

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

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

---

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

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

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

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

---

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

Механизмы планирования.

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

Список основных возможностей систем при реализации планирования:

     Создание рабочей области проекта.

     Описание WBS структуры.

     Описание различных календарей выполнения работ.

     Ввод и хранение данных по ресурсам.

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

     Ввод и хранение важных проектных дат и вех.

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

     Ресурсное планирование.

     Расчет бюджетов проектов.

     Подсчет затраченного на работу времени (временные графики).

     Сбор информации о статусе работ и пересмотр календарных планов.

     Ввод фактических затрат.

     Подсчет стоимости выполнения работ.

 

Многие пользователи могут проявить желание в использовании в самом продукте или в приложениях следующих дополнительных возможностей:

     Определение областей риска.

     Расчет показателей риска.

     Расчет возможностей по смягчению риска.

     Планирование критической цепочки риска.

     Изменение действия контроля.

 

Критерии для анализа ПО управления проектами.

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

     общая информация о ПО;

     системная архитектура и пользовательский интерфейс;

     функциональность;

     ограничения;

     маркетинговая информация.

 

Вопрос 4. Процесс выбора программного обеспечения.

 

Процесс выбора ПО включает следующие шаги:

1.  Определение необходимых данных. Для этого нужно ответить на следующие вопросы:

     Каковы ожидаемые характеристики проектов?

     Какое количество ресурсов потребуется для выполнения проектов?

---

     Сколько организаций будет участвовать в проекте?

 

2.  Анализ типов принимаемых решений, которые должно поддерживать ПО.

3.  Формирование списка критериев для выбора наиболее подходящего ПО.

 

Существуют различные модели оценки ПО. Наиболее распространенной является балльная модель: каждому критерию присваивается вес в соответствии с оценкой его значимости, например, в диапазоне от 1 до 5 (1 – совсем не важен, 5 – очень важен). В процессе оценки реализация каждого критерия в ПО оценивается значением от 1 до 10. Затем оно переводится в баллы умножением на соответствующий вес. В результате подводится общий балл ПО, который дает возможность сравнивать различные программные средства.

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

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

Помимо этого, необходимо оценить:

     Достаточными ли возможностями обладают программные алгоритмы, чтобы правильно и эффективно составлять календарные планы?

     Можно ли повторять расчет и получать при этом верный результат?

     Можно ли не выходить за рамки определенных ограничений?

     Соответствует ли график планирования ресурсов графику выполнения работ?

     Правильным ли является расчет стоимости проекта с учетом объема работ?

 

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

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

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

---

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

 

Таблица 9.

 

---

Смотрите также файлы

• Бизнеспланирование Тема Необходимость оценки внешней среды в бизнес.pdf

• Доходы и блогосостояние населения Различные концепции принципов социальной справедливости в распределении.pptx

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

• Отчет по ознакомительной практике обучающийся гр. Мтм22.docx

• Конструкции 14 Водопроводные полиэтиленовые.docx