Создание плана развертывания решения EPM: технический документ

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

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

Вы также можете ознакомиться с другими техническими документами колонки "Вести с передовой".

Создание плана развертывания решения EPM

"Вы можете помочь нам установить систему EPM и запустить ее в работу за несколько дней?" — это один из вопросов, которые приходится очень часто слышать сотрудникам компаний, занимающихся развертыванием корпоративных систем управления проектами (Enterprise Project Management, или EPM). Вне зависимости от размера организации лаконичный ответ на него, к сожалению, — нет. Проблема не в технологиях, а в целом ряде вопросов, связанных с политиками, процессами, процедурами и методами, которые могут привести к коренным изменениям в работе организации.

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

1. Формирование группы по развертыванию системы EPM

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

Ниже описаны основные шаги этого этапа.

Определение ключевых заинтересованных лиц

Еще до начала проекта часто уже есть одно ключевое заинтересованное лицо. Обычно это один из руководителей, который считает большим упущением отсутствие подобной системы. Это неплохая отправная точка, но этого отнюдь не достаточно для того, чтобы довести проект до успешного завершения. Критически важным для развертывания EPM является определение владельца системы. Сделать это нужно как можно скорее. Владелец — это лицо, которое будет пользоваться преимуществами готовой системы и поэтому считает оправданными те усилия, которые необходимо затратить на ее реализацию. Возможно, также существуют один или несколько ответственных спонсоров. Ими могут быть руководящие сотрудники, которые получат какую-то пользу от конечных результатов, или же люди, которые будут работать над проектом вплоть до его завершения, а затем будут очень мало сталкиваться со средой EPM. Без ответственного спонсора можно обойтись. Но владелец у системы должен быть обязательно.

Определение внутренних квалифицированных ресурсов

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

Привлечение внешних специалистов (при необходимости)

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

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

И нужно ли говорить о том, что к этому проекту необходимо относиться именно как к проекту? Как бы странно это ни звучало, при реализации проектов по развертыванию EPM организации чаще всего игнорируют те элементы, без которых невозможен любой другой проект (это напоминает поговорку "сапожник без сапог"). Итак, не забудьте составить календарный план, бюджет и устав проекта, выделить достаточно ресурсов и т. д.

Время для выполнения этой работы: четыре недели.

2. Определение бизнес-целей

Итак, рабочая группа собрана. Пора приниматься за дело! Теперь нужно определить масштаб проекта, разбить его на этапы, если он слишком велик, а затем создать план работы.

Ниже описаны действия, которые нужно выполнить на этом этапе.

Совещания с руководителями и заинтересованными лицами

Этого шага нельзя избежать. Главная цель создания среды EPM — помочь руководству и конечным пользователям эффективнее принимать решения. По этой причине соответствующим руководящим сотрудникам в самом начале потребуется уделить некоторое время на то, чтобы помочь определить, для принятия каких решений предназначена система. Я уже писал о том, как проводить подобные совещания (см. технический документ Действия покупателя решений), но главное не в том, как их проводить, а в том, чтобы они состоялись.

Это шанс для рабочей группы, занимающейся развертыванием, привлечь внимание руководства к двум очень важным вещам. Во-первых, это активное участие руководителей в процессе, их готовность затратить определенные усилия и заинтересованность в конечных результатах. Во-вторых (что гораздо важнее), это ожидания руководства. Одним из наиболее часто встречающихся ожиданий является то, что проект можно завершить за несколько дней или хотя бы недель. Когда руководство осознает, какие усилия потребуются на самом деле, его поддержка может улетучиться. Лучше узнать об этом сразу, чем приступать к работе, которую вряд ли удастся выполнить из-за нехватки времени или ресурсов.

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

Определение влияния на функции руководителей

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

Определение приоритетов бизнес-целей и создание сводного плана развертывания

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

Установка вех и метрик

Мы ведь руководители проекта, не так ли? Давайте введем в проект ряд вех и измеримых показателей (метрик), на которые следует ориентироваться. При развертывании любой корпоративной системы важно следить за тем, выполняется ли проект в соответствии с намеченным курсом.

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

Время для этой работы: четыре недели.

Этап 1

На каждом этапе необходимо будет повторно выполнить ряд задач. Шаги 3–9 являются частью одного этапа.

3. Инвентаризация процессов

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

Процессы, которые уже существуют и могут быть сохранены

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

Процессы, которые необходимо разработать

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

Рабочие совещания по процессам

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

Корректировка затронутых функций руководства

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

Итоговым результатом должен стать черновой вариант руководства по процессам.

Время на выполнение этой работы: четыре недели.

4. Внедрение, адаптация и разработка процессов

Анализ, адаптация и принятие разработанных процессов

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

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

Время на окончательную подготовку руководства по процессам: восемь недель.

5. Оценка и выбор средств EPM

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

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

Получение ответов от поставщиков

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

Короткий список

Даже если вы рассматриваете только один продукт, но возможных исполнителей несколько, определитесь, с кем бы вы хотели встретиться лично.

Презентации поставщиков и исполнителей

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

Выбор и приобретение продукта

Итак, настало время совершить крупную покупку. До того как вы приступили к чтению этой статьи, вы наверняка считали, что именно с этого все и начинается. Но не переживайте. Мы наконец добрались до этой стадии. Выберите систему EPM и оформляйте заказ на покупку!

Результат этого этапа — новенький продукт EPM на вашем столе.

Время, необходимое для этой работы: восемь недель.

6. Проектирование и настройка автоматизации

Применение проектной документации по процессам к выбранному средству EPM

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

Разработка и внедрение стандартов

Потребуется ввести множество стандартов. Каждый из них несет оказывает влияние на архитектуру и проект системы. Например, часто бывает, что упущен из виду календарь. Нужен один календарь или несколько? Предусмотрены ли календари ресурсов? Кто будет обладать полномочиями на их изменение? Известны ли последствия изменения календаря ресурсов для календарного плана и данных о ходе выполнения работ? И так далее… Вот некоторые элементы системы EPM, для которых требуются стандарты:

  • календари;

  • соглашения об именовании;

  • иерархия ресурсов;

  • загрузка ресурсов проектной и внепроектной работой;

  • ставки и затраты;

  • роли и обязанности;

  • структура утверждения;

  • иерархии проектов и задач;

  • структурная декомпозиция работ и другие структуры кодирования;

  • управление документами;

  • шаблоны взаимодействия;

  • шаблоны проектов.

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

  • разработка и внедрение собственного кода;

  • проектирование и реализация панелей мониторинга;

  • проектирование и создание ссылок на внешние системы;

  • проектирование и реализация рабочего процесса;

  • разработка и реализация отчетов;

  • разработка и создание обучающих курсов по работе с системой EPM;

  • анализ проекта совместно со всеми затронутыми сторонами.

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

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

7. Пилотное развертывание решения EPM

Теперь, когда система готова к работе, необходимо определить пилотную группу и предоставить ей доступ к системе.

Этап 1: установка и настройка системы и перенос данных

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

Обучение

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

Выполнение активных проектов

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

Анализ и документирование полученного опыта

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

Время на выполнение пилотного проекта и анализа: двенадцать недель.

8. Развертывание системы, созданной в рамках первого этапа, в производственной среде

Ввод в эксплуатацию

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

Время, требуемое для развертывания (сильно зависит от общего числа пользователей): четыре недели.

9. Анализ и корректировка сводного плана развертывания

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

Время на выполнение этого этапа: две недели.

10. Этап 2: повторите шаги 3–9

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

Вы подсчитали общую продолжительность всех шагов первого этапа? Она составляет 58 недель. Ниже показан сводный календарный план шагов, описанных выше.

Диаграмма Ганта, представляющая процесс, который занимает более 58 недель

Конечно, каждая организация имеет свои особенности. На общую продолжительность проекта влияет множество факторов. Наиболее важный из них — зрелость существующих процессов управления корпоративными проектами. Далее следует размер организации и сложность ее структуры. Очевидно, что проще развернуть систему EPM в организации, размещенной в одном здании, чем в имеющей множество подразделений и офисов в разных городах и даже странах.

Календарный план каждого конкретного развертывания будет иметь свои особенности, и не всегда он будет короче приведенного здесь. Чаще всего звучат настойчивые требования уложить расписание в несколько дней или недель, но для успешного развертывания крайне необходимо учитывать не только то время, которое требуется для установки программного обеспечения EPM.

Об авторе

Крис Вандерслуис (Chris Vandersluis) — основатель и президент компании HMS Software, расположенной в Монреале, Канада, и являющейся партнером Майкрософт со статусом Microsoft Certified Partner. Он получил степень по экономике в университете Макгилла и имеет более чем 30-летний опыт работы в области автоматизации систем управления проектами. Он много лет является членом Института управления проектами (PMI) и оказывал содействие в основании местных отделений группы Microsoft Project Users Group (MPUG) в Монреале, Торонто и Квебеке. Крис публиковался в таких изданиях, как Fortune, Heavy Construction News, журнал Computing Canada и PMI PMNetwork, а также ведет колонку в Project Times. Он преподает углубленный курс управления проектами в университете Макгилла и часто выступает на специальных мероприятиях ассоциации управления проектами в Северной Америке и по всему миру. Компания HMS Software является разработчиком системы TimeControl, предназначенной для учета рабочего времени в рамках проектов, и с 1995 г. является партнером со статусом Microsoft Project Solution Partner.

Вы можете написать Крису Вандерслуису по следующему адресу электронной почты: chris.vandersluis@hms.ca

Если вы хотите прочитать другие статьи Криса Вандерслуиса, посвященные управлению корпоративными проектами, посетите сайт EPM Guidance компании HMS (http://www.epmguidance.com/?page_id=39).

Совершенствование навыков
Перейти к обучению
Первоочередный доступ к новым возможностям
Присоединиться к программе предварительной оценки Office

Были ли сведения полезными?

Спасибо за ваш отзыв!

Благодарим за отзыв! Возможно, будет полезно связать вас с одним из наших специалистов службы поддержки Office.

×