Если СКПК попадают в
диапазон $200 – 800, то профессиональные СУП могут
стоить заметно больше $5000. В настоящее
время существует несколько сотен систем,
так или иначе реализующих функции СКПК.
Однако разнообразная «направленность»
и «раскрученность» их делают свое ограничительное
дело. Реально на российском рынке стабильно
присутствует не более 10 систем. Среди
них есть и отечественные разработки.
Принципиальных функциональных
отличий между СКПК начального уровня
на самом деле не так много. Практически
все они имеют сходный набор
стандартных функций:
- поддержка расписания из неограниченного количества операций с учетом приоритетов операций, расчет критического пути, вычисление резервов времени; длительность в часах, днях, неделях или комбинированная;
- умение работать с пользовательскими календарями для операций и ресурсов;
- поддержка всех видов связей, типов работ, типов ресурсов;
- способность работать со структурной декомпозицией работ;
- возможность выполнения выборки, сортировки, группировки, суммирования по кодам работ;
- поддержка основных видов визуального представления (диаграмма Ганта, таблица работ/ресурсов/связей, гистограммы ресурсов).
В отличие от СКПК, профессиональные
системы управления проектами в
своей функциональности уже заметно
отличаются друг от друга. И это, как
правило, уже не отдельные программы, а комплексы,
в состав которых входят различные утилиты
и модули, предназначенные для решения
специфических задач.
Интегрированное использование программного
обеспечения для управления проектами
В организации можно
выделить, по крайней мере, три уровня, на которых
происходит управление проектами:
1. Уровень высшего
руководства, на котором происходит
определение целей и задач
предприятия, принимается решение
о финансировании, оценивается приоритетность
проектов.
2. Стратегический уровень, состоящий из профессионалов
по управлению проектами, занимающихся
планированием и контролем корпоративных
проектов. Как правило, этот уровень представляется
весьма малым количеством людей, основная
обязанность которых - именно управление
проектами, и которые в своей работе опираются
на программное обеспечение по управлению
проектами. Миссия подобных профессионалов
является ключевой в организации. Они
работают как группа поддержки по управлению
проектами, даже если официально им не
дают такое название.
3. Уровень операций, для
которого работа с программным
обеспечением по управлению проектами
вторична. Это ответственные за
проекты на местах, менеджеры
проектов, руководители групп. На
уровне операций, конечно же, требуется
инструмент по управлению и контролю за проектом, но на непостоянной
основе. Например, менеджер проекта может
уделить этому лишь несколько часов в
месяц.
Несомненно, нужна интеграция
программного обеспечения трех уровней
для поддержки информационных потоков
в организации. Каждый уровень управления характеризуется
своими специфическими требованиями к
программному обеспечению.
Требования к интегрированной
системе по управлению проектами
универсальны и не зависят от специфики
организации. Модель обмена данными можно упрощенно представить следующим
образом:
Поток данных по проекту
идет в направлении снизу вверх,
от уровня операций к стратегическому
уровню, на котором происходит обобщение
поступивших сведений, и уже на
уровне высшего руководства данные
поступают в виде отчета, предоставляющего данные по проекту в достаточно
общем виде.
На каждом уровне управления
проектами к программному обеспечению
предъявляются характерные требования.
Требования к программному
обеспечению по управлению проектами.
Уровень высшего
руководства
Для данного уровня (на самом деле у высшего
руководства не всегда есть желание работать
с системами управления проектами) самым
главным требованием является простота
использования. Руководство, если у него
появилась потребность работать с ПО по
УП, будет делать не очень часто, и не захочет
тратить на изучение системы больше 2-3
дней. Следующей важной особенностью является
презентационный характер форм предоставления
информации по проектам, так как руководитель
может использовать программное обеспечение
для подготовки презентаций для клиентов.
Средство для предоставления информации
в самом общем виде на одном листе в форме
диаграммы Гантта или кривой затрат –
самое стандартное требование. Руководство
не будет тратить время на ввод данных,
так что должна быть возможность для получения
данных из других источников, в том числе
с других уровней управления проектами.
В то же время может понадобиться средство
для планирования сверху вниз, если нужно
будет детализировать построенный руководством
план на другом уровне управления.
Стратегический
уровень
Требование легкости
изучения и "дружелюбный интерфейс"
не упоминается в запросах на программное
обеспечение специалистов-профессионалов.
Базовым является мощность средств
временного анализа, ресурсного планирования,
стоимостного анализа и анализа рисков. Ведь
предполагается, что пользователь не только
знает, как вызвать процедуру системы,
но и понимает заложенный в нее алгоритм.
Кроме того, очень часто требуется интегрировать
данные о проектах с данными из других
приложений, например, из бухгалтерских
программ и т.д. Обязательно должно быть
предусмотрено средство объединения нескольких
проектов для обобщенного анализа, управления,
контроля.
Важна возможность ввода
реальных данных и сравнения предварительных
планов с фактическим выполнением для внесения корректирующих
операций. Гибкая отчетность нужна, поскольку
менеджерам-профессионалам приходится
настраивать отчеты не только для себя,
но и для сотрудников, работающих с проектом
на других уровнях управления.
Уровень операций
Требование "банальности"
при работе с системой всегда выставляется
под №1 в списке требований. Сотрудники
не могут выделять слишком много
времени для поддержания данных
по проекту в актуальном состоянии.
Наиболее часто произносится жалоба
со стороны менеджеров проектов на то, что масса времени
у них уходит на ввод данных по проекту.
Однако возможность предоставления отчетов
в графическом виде важна для координации
действий исполнителей в проекте, что
входит в непосредственные обязанности
менеджера проекта.
Уровень высшего руководства
|
Стратегический уровень
|
Уровень операций
|
Легкость в применении
Возможность получать демонстрационные
отчеты
Мощные возможности
обобщения сведений
Средства для интеграции
с данных из других программных приложений
Процедуры для планирования сверху вниз
|
Мощность временного,
ресурсного, стоимостного планирования,
анализа рисков
Возможность интеграции
с другими приложениями
Средства для свертывания
данных по проекту (предоставление отчетов
руководству) и углублению для планирования на более детальном уровне
Средства для контроля
за реализацией проекта
Гибкость при настройке
выходных форм отчетности |
Простота использования
Легкость изучения
"Прозрачность" процедур
ввода данных
Наглядность |
Как строится
интегрированная система по управлению
проектами?
Выбор программного обеспечения
по управлению проектами зачастую зависит
от того, с какого уровня исходила инициатива.
Часто получается, что самый активный
уровень навязывает другим программное
обеспечение, отвечающее непосредственно их требованиям.
1. Выбор производится
руководством
За |
Против |
Внедрение, "по определению",
быстро продвигается
Методы внедрения поддерживаются
руководством
Благодаря поддержке
легко выискиваются финансовые и
людские средства для внедрения |
Руководство может быть
не осведомлено о запросах нижних
уровней
Система может оказаться
неэффективной для работы менеджеров-профессионалов
|
2. Выбор проводится
на стратегическом уровне
За |
Против |
Продукт, скорее всего, окажется
достаточно функциональным
Эксперты по управлению
проектами в компании смогут давать
рекомендации пользователям других
уровней
Система окажется достаточно
удачно интегрируемой с другим программным
обеспечением |
Может потребоваться
интенсивный тренинг по ПО
Для реального использования продукта придется вводить
много данных на других уровнях
|
3. Выбор производится на уровне операций
За |
Против |
· Выбранная система
легко применяется
· Большое число пользователей
уже использует систему, чаще всего просто
принимается решение о поставке интегрированной системы
управления проектами
· Так как система не
многофункциональна, она наверняка дешевая
|
· Программное обеспечение
низкого уровня не удовлетворит запросов
стратегического уровня и уровня высшего
руководства
· Так как программное обеспечение навязано
стратегическому уровню, с его стороны
будет сопротивление в ответ
· Малофункциональное
программное обеспечение будет интегрироваться
с другими программами при затрате дополнительных
усилий и финансов |
Какой из подходов наиболее удачен? Никакой, так как
при каждом способе приходится жертвовать
потребностями членов уровней управления,
не участвующего в выборе. Предлагаемая
схема выбора программного обеспечения
по управлению проектами в организации
состоит из следующих шагов:
1. Анализ требований
2. Анализ рынка
3. Выбор программного
обеспечения
Важно не делать обобщений
при составлении списка требований
и не пытаться найти такое средство,
которое удовлетворяет всем запросам.
Нельзя корректно определять приоритеты,
рассматривая списки требований различных
уровней. Конечно, можно исходить из самых
высоких запросов стратегического уровня,
предположив, что пользователи других
уровней изучат и будут использовать лишь
часть функций системы, но такое решение
будет дорогим и утяжеленным.
Шесть признаков корпоративных
информационных систем управления проектами
- Распределение функций системы по ролям в проекте
В реализацию проектов вовлечено
множество сотрудников организации,
поэтому корпоративная система
управления проектами (Enterprise Project Management - EPM) не может состоять
из одного программного продукта «на все
случаи жизни». Пользователям, находящимся
в разных подразделениях на разных уровнях
управления, для выполнения своих обязанностей
в любой момент времени должна быть доступна
необходимая информация о проекте. Высшему
руководству, например, требуются лаконичные
и удобные формы представления информации
о портфеле проектов, отчеты по отклонениям,
дающие возможность проследить за ходом
выполнения отдельных проектов, соблюдением
бюджетных и временных ограничений, а
также позволяющие определить, что еще
необходимо сделать. У руководителей проектов
должна быть возможность разрабатывать
различные сценарии развития событий,
чтобы завершить проект в заданные сроки.
Исполнителям конкретных работ нужно
регулярно получать интерактивный список
задач на отчетный период с возможностью
отчитываться в их фактическом выполнении.
Аналитикам требуются средства для моделирования
всех возможных рисков и вероятных сценариев
развития многих проектов в комплексе,
с учетом их взаимного влияния друг на
друга.
- Поддержка глобальных иерархических структур
- EPM-система должна обеспечивать планирование, анализ и контроль всех проектов компании в рамках единой структуры или иерархии проектов. Эта структура должна предусматривать как планирование сверху-вниз, так и снизу-вверх, а также предоставлять возможность сравнения альтернативных вариантов для обеспечения уверенности в том, что тактические планы ведут к достижению проектных целей, поставленных на более высоком уровне.
- Группировка проектов должна иметь определенный смысл для каждого участника, использующего информацию о проекте. Финансовому директору, возможно, требуется взгляд на проекты через призму структуры статей затрат, связанной с корпоративной ERP или финансово-бухгалтерской системой. Для ресурсного менеджера более важна иерархия ресурсов, дающая возможность назначить на работы исполнителей, обладающих определенной квалификацией. Руководитель проекта ориентируется на структуру декомпозиции работ проекта.
- Контроль одновременного использования ограниченных ресурсов компании во многих проектах
- В последнее время уже никто не спорит с тем, что время сотрудников компании – наиболее дефицитный ресурс. Назначение нужных людей на выполнение работ проекта, эффективное использование имеющихся трудовых ресурсов вне зависимости от их территориального расположения – необходимые условия успешного управления проектами в масштабах всей компании.
- EPM-система призвана помогать руководству принимать решения о том, кто и в каком проекте будет участвовать. Кроме того, она дает возможность планировать ресурсы на основе ролей (специальностей) задолго до того, как будут известны конкретные исполнители работ. Руководитель отдела кадров должен иметь возможность анализа предстоящих проектов в разрезе будущей потребности в персонале. К примеру, проследив увеличение в будущем числа проектов, которые потребуют участия JAVA программистов, он может заранее спланировать способы удовлетворения этой потребности – например, путем найма программистов извне или обучения имеющегося персонала. А у руководителей функциональных подразделений должна быть возможность ответить на вопрос, когда специалисты дефицитных специальностей освободятся для работы на других проектах.
- Обеспечение обмена информацией внутри команды проекта в режиме реального времени
- Ключевой признак EPM-системы – обеспечение возможности своевременного предоставления руководству проекта необходимой информации о его выполнении. Часто при использовании традиционных инструментов управления проектами лица, принимающие решения, получают данные о ходе реализации проекта слишком поздно и уже не могут ничего изменить. Средства корпоративного управления проектами должны предоставлять свободный доступ к проектной информации в режиме реального времени. Если что-то может пойти не по плану, руководство должно узнавать об этом сразу же, а не через неделю или две на очередном собрании.
- Информационные потоки проходят через все заинтересованные подразделения компании, эффективно связывая между собой все уровни управления. Лица принимающие решения обладают всей необходимой им информацией для принятия адекватных решений в кратчайшие сроки. Руководители проектов имеют свободный доступ к актуальной информации, позволяющей им оценивать различные варианты развития событий и выбирать наиболее оптимальный с точки зрения сроков, трудозатрат и стоимости.
- Наглядное представление информации о состоянии проектов
- Несомненно, Вы слышали фразы «Что не можешь измерить, тем не можешь управлять» или «Что измеримо, то выполнимо». Компании, использующие разнообразные методики оценки состояния проектов, имеют больший потенциал для достижения лидирующих позиций в своей отрасли. Поэтому EPM-система должна обладать хорошим функционалом в области контроля выполнения проектов.
- В решениях компании Primavera оценка состояния проекта - это не просто анализ прошедших событий, это инструмент, ориентированный на будущее, позволяющий определить не только то, что произошло, но и то, из-за чего это произошло. Кроме того, компании смогут определять неблагоприятные тенденции заблаговременно, когда еще есть время что-то исправить. При благоприятных обстоятельствах руководство сможет увидеть имеющиеся возможности и использовать их для усиления своих позиций. Применение программного обеспечения Primavera повышает прозрачность проектов в масштабах всей организации, что непременно ведет к повышению вероятности успешной реализации проектов.
- Кроме того, программные продукты компании Primavera содержат инструменты для анализа взаимного влияния проектов. Информация предоставляется в удобной и понятной для всех форме - участникам проекта не придется тратить много времени для ее восприятия. Таким образом, максимальное внимание уделяется решению конкретных задач для успешного достижения целей проекта.
- Готовность к интеграции
- EPM-система должна иметь возможность интеграции с финансовыми и другими информационными системами предприятия. Интеграция может осуществляться на основе как стандартных, так и специально создаваемых модулей. Вопросы интеграции играют важную роль в обеспечении качества передачи информации в компании. Как только происходят какие-либо изменения в проектах, специалисты всех подразделений компании должны иметь возможность сразу же увидеть последствия этих изменений.
- Мазур И.И., Шапиро В.Д., Ольдерогге Н.Г. Управление проектами: Учебное пособие. – М.: Омега-Л, 2004. – 664 с.
- Товб А.С., Ципес Г.Л. Управление проектами: стандарты, методы, опыт. – М.: ЗАО «Олимп – Бизнес», 2003. – 240 с.
- Богданов В.В. Управление проектами в Microsoft Project 2007: Учебный курс. – СПб.: Питер, 2008. – 604 с.
- Куликов Г.Г., Никулина Н.О., Речкалов А.В. Управление проектами на основе системного моделирования: Учебное пособие. – Уфа: УГАТУ, 2009. – 171 с.
- www.pmi.ru
- www.projectmanagement.ru
- www.aproject.ru
- www.spiderproject.ru
- www.sovnet.ru