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

В.И. Либерзон
Технологии управления СПАЙДЕР
E-mail: [email protected]
ПРОГРАММНЫЕ СРЕДСТВА УПРАВЛЕНИЯ ПРОЕКТАМИ
- ОБЗОР РЫНКА И ПРОБЛЕМА ВЫБОРА
1. ВВЕДЕНИЕ
На Российском рынке программных средств управления проектами представлены
пакеты, сильно различающиеся своими функциональными возможностями и
ценой. Этот рынок можно условно подразделить на 2 основные группы недорогие пакеты (до 1000 долларов), ориентированные на начинающих или
непрофессиональных менеджеров, и более дорогие профессиональные пакеты
(до 15000 долларов).
К недорогим можно отнести американские пакеты Microsoft Project, Time Line, CASuperProject, SureTrak. Разработчики этих программ особое внимание уделяют
легкости использования и обучения.
Из профессиональных пакетов на Российском рынке представлены Российский
пакет Spider Project и американские Artemis Schedule Publisher, Primavera Project
Planner, Open Plan, Artemis Project View. Эти пакеты более ориентированы на
широту функциональных возможностей управления.
Российские пользователи часто путают программы управления проектами и
программы оценки инвестиций (Project Expert, Альт Инвест, Comfar и т.п.). Это
совершенно разные программные средства. Программы управления проектами
предназначены для управления проектом (планирования, мониторинга, анализа)
на всех этапах его жизненного цикла - от инициации и до завершения, в то время
как программы оценки инвестиций предназначены лишь для начальной стадии
управления проектом - оценки того, заслуживает ли проект исполнения. На
последующих стадиях программы оценки инвестиций уже не могут быть
использованы и для управления проектом бесполезны.
2. ВЫБОР ПАКЕТА
Правильный выбор пакета очень важен для успешного внедрения управления
проектами в организации и зависит от многих факторов. Выбор пакета (и не
только управления проектами) - это сам по себе проект, который требует
серьезного подхода, затрат, планирования, контроля и т.д.
Итак, рассмотрим, из каких работ состоит этот проект.
Первая фаза проекта - Анализ, состоящая из следующих работ (в скобках указан
код работы):
1) Анализ рынка (1010),
2) Технические требования (1020),
3) Управленческие требования (1030),
2
4) Контакт с поставщиками (1040),
5) Конец анализа (1050).
Вторая фаза - Принятие решения, исполнение которой начинается после
получения материалов от поставщиков программной продукции:
6) Анализ спецификаций (1060),
7) Проверка ссылок (1070),
8) Анализ ДЕМО (1080),
9) Проверка сопровождения (1090),
10) Принятие решения (1100)
Расписание выполнения работ, ресурсы, назначенные на выполнение работ,
взаимосвязи работ представлены на диаграмме Гантта (рис. 1), полученной при
помощи пакета Spider Project.
Рис.1 Диаграмма Гантта проекта "ПОКУПКА ПАКЕТА".
В нашем примере на исполнение проекта назначены два специалиста системный аналитик и менеджер. В реальном проекте число специалистов,
задействованных в выборе пакета, может быть большим.
Поясним подробнее, что подразумевается под каждой из операций проекта
"ПОКУПКА".
3
Анализ рынка заключается в определении перечня программных
продуктов нужной тематики, представленных на рынке, а также реквизитов их
поставщиков. Исполнитель – Аналитик.
Технические требования - определение технических требований,
выдвигаемых к программам. Эти требования определяются соответствующей
политикой организации (ориентации на программы тех или иных фирм),
имеющимся парком компьютеров и программным обеспечением, уже
используемым в задачах управления (типы компьютеров, операционные системы,
сети и т.д.). Исполнитель – Аналитик.
Управленческие требования - это требования к функциональным
характеристикам программ управления проектами, определяемые проектами
вашей организации. Это - наиболее важные требования и мы посвятим им
отдельный раздел этой статьи. Как бы ни была совершенна программа с точки
зрения программных решений, это никак не сможет компенсировать отсутствие
каких-либо необходимых для управления функций. Исполнитель – Менеджер.
Контакт с поставщиками - посылка запросов (либо визиты в
соответствующие фирмы) с просьбой предоставить возможно более полный
набор информации о программном продукте - спецификации, Демо версии,
условия продажи и сопровождения и т.д. Исполнители – Аналитик и Менеджер.
На фазе принятия решения необходимо выполнить следующие работы:
Анализ спецификаций - определение того, насколько программа
удовлетворяет выдвигаемым техническим и управленческим требованиям.
Исполнитель – Аналитик.
Проверка ссылок - если программа нашла применение на близких по
профилю предприятиях, то полезно установить контакт с пользователями
программы и навести справки о том, насколько полно она используется и
удовлетворяет поставленным целям. Исполнитель - Менеджер
Анализ Демо версий - демонстрационные версии программ (особенно,
если они рабочие, а не перечень слайдов) позволяют представить, как программа
функционирует, насколько удовлетворяет выдвигаемым требованиям, насколько
легка в использовании и обучении. Исполнитель – Аналитик.
Проверка сопровождения - внедрение таких технологически не простых
программ, как программы управления проектами, требует не только технической,
но и методической поддержки, проведения обучения персонала, а часто и
настройки программы на специфику организации. Без возможности такого
сопровождения полное (а не на 10%) использование возможностей программ
управления проектами практически невозможно, если только в вашей
организации не имеются специалисты, уже имеющие богатый опыт работы с
аналогичными программами. Для больших компаний может оказаться важным
контакт с разработчиками, которые могли бы выполнить работы по адаптации
программ к специфическим задачам и проектам компании. Исполнитель –
Аналитик.
Оценки сроков исполнения работ и необходимых специалистов в нашем
примере условны - это зависит от специфики конкретной организации, но
перечисленные шаги необходимы для разумного выбора используемых программ.
Взаимосвязи работ проекта представлены также на сетевой диаграмме
(рис.2).
4
Рис.2. Сетевая диаграмма проекта "ПОКУПКА"
Если же в вашей организации нет специалистов, знакомых с программами
управления проектами, и управление проектами - новая для вас область, то мы
рекомендуем обращаться в консалтинговые фирмы, которые проведут
обследование ваших потребностей и помогут выбрать такую программу, которая
наиболее полно эти потребности удовлетворяет. Следует заметить, что не цена
программы представляет собой основную долю затрат на ее внедрение.
Необходимо обучить специалистов, перестроить саму систему управления и т.д.
Поэтому и программу надо подбирать под свои задачи. Избыточная сложность
программы, связанная с наличием большого числа неиспользуемых в ваших
проектах функций - это тоже затраты (даже без учета более дорогой цены такой
программы) - затраты времени и денег на обучение, лишние действия при
эксплуатации и т.д. В то же время чересчур примитивная программа не позволит
вам решать необходимые задачи управления, может не содержать необходимых
функций, давать не оптимальные управленческие решения, что может обернуться
еще большими потерями. Поэтому при выборе следует проконсультироваться со
специалистами специализированных консалтинговых фирм (не путать с фирмами
– дистрибьюторами и программ), тем более, что в нашей стране они уже
появились.
3. УПРАВЛЕНЧЕСКИЕ ТРЕБОВАНИЯ
В приведенной ниже таблице представлен пример того, как могут быть
сформированы
основные
управленческие
требования
для
некоторой
организации. Не стесняйтесь задавать вопросы поставщикам пакетов, просите
показать как реализованы те или иные важные для вашей деятельности функции.
5
По тому, как вам будут отвечать, вы сможете оценить и будущее сопровождение
пакетов.
ПЕРЕЧЕНЬ ПАРАМЕТРОВ ДЛЯ ОЦЕНКИ ПРИМЕНИМОСТИ ПАКЕТА УП
(УПРАВЛЕНЧЕСКИЕ ТРЕБОВАНИЯ)
№
1
2
3
Наименование
Требования (например)
Требования к
размерности
Требования к
языку:
Требования к
структуризации
Число работ, ресурсов, связей и календарей.
4
Требования к
типам работ
5
Требования к
типам ресурсов
Требования к
назначениям
ресурсов
6
7
Требования к
календарям:
8
Требования к
учету затрат:
Работа с пакетом на русском языке.
1)
Необходимо иметь возможность структуризации работ и получения
отчетности по структурным группам работ;
2)
Необходимо иметь возможность группировки и получения отчетности
по группам ресурсов (цехам, бригадам и т.д. - ОСР);
3)
Необходимо иметь возможность получения отчетности о плане и ходе
выполнения отдельных контрактов (договоров);
4)
Необходимо иметь возможность группировки работ для получения
отчетности в соответствии с бухгалтерскими счетами;
5)
Необходимо иметь возможность создавать собственные
дополнительные структуры.
1)
Работы могут быть фиксированной длительности, либо с
длительностью, определяемой объемом работ и производительностью
назначенных ресурсов (причем производительность у различных ресурсов
может различаться);
2)
Работы могут быть фиктивными (работы нулевой длительности),
отражающими наступление тех или иных событий, причем эти фиктивные
работы могут требовать определенных ресурсов;
3)
У работ может быть условная длительность, определяемая
длительностью других работ (Hammock activities, Headers).
Ресурсы могут быть возобновляемыми, расходуемыми и
производимыми.
1)
Возобновляемые ресурсы могут назначаться на работы жестко, либо с
возможностью выбора из совокупности (skill scheduling);
2)
У возобновляемых ресурсов могут быть производительности,
определяющие длительность работы, либо наоборот, длительность работы
определяет их производительность;
3)
Расход материальных ресурсов может задаваться по каждой работе и
зависеть, либо не зависеть от ее объема;
4)
Кроме того, расход материальных ресурсов может быть связан с
работой возобновляемых ресурсов и зависеть, либо не зависеть от
длительности их использования (пример: ГСМ и автомобиль);
5)
Необходимо иметь возможность задавать неравномерное во времени
потребление ресурсов на работах;
6)
При определении потребностей работы в ресурсах необходимо иметь
возможность использовать НСИ.
1)
Каждый из ресурсов системы может иметь свой собственный
календарь, учитывающий отпуска, неполные рабочие недели и т.д.;
2)
Работы проекта также могут иметь собственные календари.
1)
Стоимость работы складывается из постоянной составляющей,
стоимости использования возобновляемых ресурсов и стоимости материалов
(стоимости назначений);
2)
При назначении стоимостей ресурсов необходимо иметь возможность
автоматизированного использования НСИ;
3)
При назначении стоимостей работ необходимо иметь возможность
автоматизированного использования НСИ;
4)
Стоимость назначения может складываться из постоянной
составляющей (например - доставки), стоимости использования ресурса во
времени и стоимости расходуемых ресурсом материалов;
5)
Следует иметь возможность вести планирование и учет затрат по
6
9
Требования к
составлению
расписания
работ
10
Требования к
фильтрации
данных:
11
Требования к
учету и
контролю хода
работ
12
Требования к
связи с другими
задачами
(возможности
пакетов зависят
от способов
решения других
задач)
отдельным компонентам и центрам затрат;
6)
Пакет должен обеспечивать пользователям возможность вести
мультивалютное планирование и учет затрат;
7)
Необходимо иметь возможность включать в расписание работы,
связанные с получением доходов, такие как получение кредитов, поставки
материалов и т.п.,
8)
Необходимо иметь возможность рассчитать CASH FLOW проекта
1)
Пакет должен обеспечивать наиболее полное использование
ресурсов, а значит составляемые расписания (после выравнивания ресурсов)
должны иметь минимальную продолжительность;
2)
Пакет должен учитывать графики поставок и финансирования при
составлении расписания работ,
3)
Пакет должен составлять расписания по квалификации ресурсов (skill
scheduling);
4)
Продолжительность расписания может достигать нескольких лет (для
перспективного планирования и проектирования), а единицы времени могут
быть от часа до месяца;
5)
Должны определяться резервы работ – промежутки времени, на
которые можно отложить выполнение без нарушения срока завершения
проекта.
1)
В пакете должна быть обеспечена возможность выделения
критических работ, ключевых событий, работ, выполняемых определенными
ресурсами и другая фильтрация данных по задаваемым пользователями
критериям;
2)
Пакет должен обеспечивать возможность сортировки данных по
признакам, задаваемым пользователями;
3)
Пакет должен обеспечивать автоматизированный поиск информации
по задаваемым пользователем признакам;
4)
Пакет должен обеспечивать функцию Undo - возвращение
предыдущей информации в случае, если произведенные изменения не
удовлетворяют пользователя.
1)
Данные о ходе выполнения работ должны автоматически учитываться
при корректировке планов работ,
2)
Необходимо хранить в архиве "историю проекта" - первоначальный
(базовый) план и все существенные корректировки плана для проведения
анализа отклонений хода работ от первоначальной и последующих версий
плана;
3)
Необходимо анализировать ход выполнения контрактов и договоров.
1)
Рассчитанная в программе Управления Проектами потребность в
материальных ресурсах должна автоматически поступать в программу
управления снабжением;
2)
Производительности ресурсов на работах проекта должны
автоматически поступать из базы данных, содержащей нормативносправочную информацию – внутрифирменные нормативы;
3)
Данные о ходе выполнения проекта должны автоматически попадать
в бухгалтерскую отчетность;
4)
Нормативы по плановой потребности работ в материалах и
единичные расценки для работ различных типов должны автоматически
использоваться в расчетах;
5)
Данные о поставках материальных ресурсов и оборудования должны
учитываться при планировании работ.
Поясним некоторые требования.
Требования к размерности. Все перечисленные пакеты позволяют
управлять проектами, состоящими из тысяч работ. Недорогие пакеты при этом
используют оперативную память компьютера. Дорогие пакеты гарантируют
управление очень большими проектами независимо от оперативной памяти
компьютера. В то же время и у дорогих пакетов могут быть ограничения,
существенные для ваших целей. Так, например, Primavera Project Planner
7
позволяет учитывать при расчете расписания работ ограничения не более, чем
на 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)
позволяют моделировать производство материалов. Если в ваших проектах
материалы производятся на одних работах и расходуются на других, либо вы
хотите моделировать поставки, то это для вас серьезное ограничение в выборе
пакета.
Требования к назначениям. Управление ресурсами – ключевой элемент
реального управления. Ресурсы могут иметь различные производительности,
могут быть взаимозаменяемыми, производиться на одних работах и потребляться
8
на других. Некоторые ресурсы могут быть командными, то есть работать только
вместе, другие использоваться на работах проекта независимо.
У вас могут возникнуть и другие требования к описанию назначений.
Большинство перечисленных требований выполняется лишь в пакете Spider
Project (1, 2, 4, 6).
Требования к календарям. Не все пакеты позволяют использовать кроме
календарей ресурсов и календари работ.
Требования к учету затрат. Перечисленные требования могут
оказаться избыточными для ваших проектов. В таком составе их удовлетворяет
только пакет Spider Project. В Западных пакетах задается стоимость часа работы
ресурса и единицы материала. Стоимость работы задается через назначения
ресурсов. Однако в Западных пакетах не предусмотрена возможность
потребления материалов ресурсами. Поэтому нельзя получить отчетность по
стоимостям назначений, если у работ по несколько исполнителей, которые имеют
фиксированную составляющую стоимости, либо потребляют материалы.
Требования к составлению расписания работ. Этот показатель может
оказаться наиболее важным, если вы не собираетесь ограничивать
использование пакета управления проектами верхним уровнем управления для
получения укрупненных характеристик работ, а собираетесь действительно
управлять ресурсами проекта. Если другие показатели влияют на трудоемкость
сбора и обработки информации, возможность получения той или иной
отчетности, то плохой план работ означает серьезные прямые денежные и
ресурсные потери, а хороший - колоссальную экономию, несопоставимую со
стоимостью программ, если вы управляете серьезными проектами. Все пакеты
составят одинаковое расписание работ, если не будут учитываться ограничения
на ресурсы проекта. Но в таком расписании потребность в ресурсах в отдельные
промежутки времени может значительно превышать их наличие, не говоря уж о
том, что ресурсы потребляются неравномерно. Для приведения в соответствие
расписания выполнения работ и наличествующих ресурсов и сглаживания их
загрузки производится выравнивание - составление расписания с учетом
ограниченности ресурсов проекта.
Как показало тестирование пакетов, Западные пакеты не умеют составлять
хорошие расписания работ при ограниченных ресурсах проекта. Расписания
работ, составленные пакетом Spider Project, как правило, оказываются более
короткими, чем расписания, составленные для тех же проектов Западными
пакетами. Меньший срок выполнения работ проекта означает наилучшее
использование имеющихся ресурсов, быстрейший ввод объектов в эксплуатацию
и т.д. Любая задержка проекта означает значительные потери средств.
В частности, ни один из Западных пакетов не смог составить разумного
расписания проекта "ПОКУПКА" - по планам, составленным Западными пакетами,
проект должен занять на три недели больше времени, то есть длительность
работ при тех же ресурсах возрастает на 25%.
Кроме того, Spider Project позволяет при планировании определить
резервы сроков исполнения работ, которые можно использовать при управлении
в отличие от резервов, определяемых Западными пакетами. Дело в том, что
Spider Project каждый раз составляет два различных расписания выполнения
работ проекта - одно в режиме Как Можно Раньше (КМР), а другое - Как Можно
Позже (КМП). Во втором расписании сроки исполнения работ отодвигаются до тех
пор, пока дальнейшая задержка не приведет к нарушению каких-либо
директивных сроков, либо срока завершения проекта по расписанию КМР. Оба
расписания составляются при одинаковом составе ресурсов проекта. Резерв по
9
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. Эти программы обеспечивают возможность
10
передачи заданий и проведения учета рабочего времени (timesheet) через
Интернет. В России такой учет имеет ограниченное применение, у нас принят
учет выполненных объемов, а не затраченного рабочего времени.
4. ТЕХНИКА ВЫБОРА ПАКЕТА УПРАВЛЕНИЯ ПРОЕКТАМИ
При выборе подходящего пакета управления проектами полезно составить свой
собственный перечень существенных параметров и оценить важность этих
параметров в баллах. Пример такого перечня:
1)
Качество составляемых расписаний выполнения работ (оптимальность
использования ресурсов проекта),
2)
Размеры проекта, поддающегося расчету (количество работ, ресурсов,
связей, календарей),
3)
Возможность использования в проектах нормативных баз, присущих
области применения,
4)
Возможность проведения стоимостного анализа и формирования отчетных
документов, требуемых в области применения,
5)
Гибкость - возможность использования в проекте дополнительной
информации, присущей области применения,
6)
Возможность использования в проектах множественных иерархических
структур работ, проведения выборок и сортировок по любым используемым
показателям и в том числе, определяемых пользователями,
7)
Возможность использования в проектах различных иерархических структур
ресурсов,
8)
Возможность ввода формул и проведения дополнительных расчетов,
необходимых пользователям (не присущих стандартным расчетам характеристик
проектов),
9)
Легкость освоения,
10)
Полнота документации,
11)
Качество оформления выходных документов,
12)
Возможности экспорта и импорта данных - связь с другими программами,
базами данных,
13)
Возможность вывода информации в Интернет,
14) Возможность управления мультипроектами - планирование работы
организаций,
15) Возможность групповой работы с одним проектом,
16)
Скорость работы,
17)
Удобство работы с графическим интерфейсом,
18)
Другое – добавьте.
Можно было бы продолжить этот список, но и на этих параметрах можно
проиллюстрировать и то, как организуется разработка (политика качества) и какой
выбор при этом возникает. Так, очевидно, что добиваясь максимальной простоты
работы с пакетом придется пожертвовать его универсальностью - настройками на
предметную область, множественными структурами, формулами и т.д. А
максимизируя
скорость
расчетов
придется
пожертвовать
качеством
составляемых планов и использовать максимально простые алгоритмы
назначения ресурсов на работы проекта.
Попробуйте оценить важность для вас тех или иных параметров из составленного
перечня, например, по 10-балльной системе.
11
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Параметр
Ниже приведен пример заполнения оценочной таблицы для гипотетического
пакета:
Параметр
Пакет
Итого
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
8
7
56
3
8
24
9
7
63
6
8
48
4
6
34
7
9
63
5
9
45
4
6
24
4
4
16
5
4
20
7
6
42
8
5
40
1
3
3
9
5
45
4
5
20
2
8
16
4
6
24
Итоговая оценка пакета – 6.37 балла. Такая итоговая оценка позволит сделать
предварительный отбор пакетов для последующего более детального изучения.
4. ЗАКЛЮЧЕНИЕ
Выбор подходящего пакета управления проектами сам по себе
представляет собой проект, к которому надо отнестись со всей серьезностью.
Неправильные решения на этой стадии могут привести к значительным потерям и
к невозможности решения тех или иных задач управления. Правильный выбор
связан
с
необходимостью
проведения
серьезного
предварительного
обследования потребностей организации и специфики выполняемых проектов. К
обсуждению характеристик пакетов с поставщиками необходимо тщательно
подготовиться. Хорошо, если в фирме есть специалисты, имеющие опыт
применения программ Управления Проектами. В противном случае наиболее
приемлемым способом выполнения этого проекта является привлечение
консалтинговых фирм, знакомых с характеристиками пакетов, имеющихся на
рынке, и имеющих опыт внедрения управления проектами на различных
объектах. Правильный выбор и оптимальное применение пакетов управления
проектами дает большой экономический эффект, несопоставимый со стоимостью
пакетов и необходимых консалтинговых услуг. Неправильный выбор приведет к
непроизводительным затратам и может обернуться покупкой продукции на полку.
Ито
го
90
106
573