Статья Алексея Просницкого, РМР, MVP (Компания Leo Consulting), первоначально опубликованная здесь

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

Как правило это этапы инициации проектов, планирования, реализации и закрытия проектов.

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

 

Рисунок 1 Жизненный цикл проекта

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

Другими словами можно сказать, что проект состоит из маленьких шагов, стадий. Проект не может переходить на последующую стадию, пока, например:

  1. Не закончена предыдущая стадия (т.е. по ней не получен результат, например, назначен менеджер проекта или проект исключен из портфеля проектов и подлежит закрытию)
  2. Не принято решение руководителями компании о том, что проекту можно «идти» дальше;
  3. Не приложен тот или иной документ (например, устав, запрос на изменение);
  4. Не произведено назначение ресурсов и согласование их назначений, и пр.

В связи с тем, что во многих компаниях реализующих проекты, отсутствует автоматизированная практика перехода от одной фазы (стадии) к другой фазе (стадии) на основании полученных результатов предшествующих фаз (стадий) и проекты одного и того же типа имеют различные по своему составу жизненные циклы и стадии, в Microsoft Project Server 2010 появился функционал (demand management) для управления жизненными циклами проектов, в котором возможно:

  • Построение единых рабочих процессов по которым будут двигаться проекты в течение их жизненных циклов;
  • Стандартизация отчетности, характеризующей ту или иную стадию жизненного цикла проекта;
  • Сбор всех предложений в центральном хранилище для повышения прозрачности принятия решений по выбору того или иного проекта%
  • Утверждение руководителями тех или иных результатов по проекту.

В Microsoft Project Server 2010 есть встроенный учебный пример рабочего процесса, по которому можно запускать проекты и проводить их через преднастроенные этапы и стадии.

Но у данного учебного процесса есть недостаток. Его нельзя изменить! Ни порядок этапов, ни создать новый этап, ни удалить лишний, ни создать новую стадию, ни задать используемый в конкретной компании цикл утверждений по проекту, ни оперировать с документами по проекту. В связи с чем, многие компании разработав собственные процессы и этапы для реализации проектов на бумаге, не могут эти процессы и этапы, стандартными способами переложить на рабочие процессы, чтобы автоматизировать движение проектов по жизненному циклу в Microsoft Project Server 2010, Рисунок 2.

 

Рисунок 2 Пример этапа «Инициация проекта»

Но есть решения. И их больше чем одно:

  1. Можно нанять программиста, купить средство разработки Visual Studio и за месяца три разработать (создать, протестировать и запустить) рабочий процесс проекта.
  2. Можно нанять компанию разработчика и за месяца три разработать (создать, протестировать и запустить) рабочий процесс проекта.
  3. Можно купить конструктор рабочих процессов, Nintex или К2 (не путать с компанией К2, которая занимается организацией боев братьев Кличко), и, самое главное, самостоятельно за несколько дней запустить рабочий процесс по проекту.

Итак, что такое Nintex? Nintex это марка программных продуктов, реализуемых компанией Nintex, которая предлагает для разработки рабочих процессов проектов программный продукт Nintex Workflow for Project Server.

Nintex Workflow for Project Server устанавливается на ферму SharePoint Server, с уже установленным программным продуктом Nintex Workflow и активируется на узле Project Server.

После активации Nintex Workflow for Project Server на узле Project Server, в действиях сайта появляется новый пункт «Project Server Workflow», при выборе в котором подменю «Create Demand Management Workflow» можно начать разрабатывать методом «Drag&Drop» структуру рабочего процесса, Рисунок 3.

 

Рисунок 3 Разработка процесса в Nintex Workflow for Project Server

Принцип разработки рабочего процесса в Nintex Workflow аналогичен принципу разработки рабочих процессов в Visio – легкость и быстрота. Самое главное - любой (при наличии прав безопасности) может разрабатывать рабочие процессы.

С помощью конструктора Nintex Workflow for Project Server вы сможете:

  1. Задавать любую логику, включая циклы и разветвления, движения проектов по рабочим процессам;
  2. Создавать для разных типов проектов (ИТ, развития, строительства) собственные рабочие процессы;
  3. Задавать различные параметры согласования и утверждения проектов (или конкретная группа, или конкретная роль, или утверждение большинством);
  4. Задавать длительность прохождения проекта по стадии или по всему процессу;
  5. Оперировать документами;
  6. Утверждать проекты посредством электронных сообщений (СМС);
  7. Отслеживать динамику движения проектов;
  8. Интегрировать разные данные по проекту с другими информационными системами (SQL, SAP, CRM и др.).

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

 

Рисунок 4 Отслеживание рабочего процесса в Nintex Workflow for Project Server

Благодаря конструктору рабочих процессов Nintex Workflow for Project Server, вы сможете «оживить» ваши процессы разработанные в «Положении по управлению проектами», ваши коллеги получат в лице готовых запущенных процессов «нить Ариадны», которая будет их вести через разработанную методологию и даст сбиться с пути эффективного управления проектами.