GPS-навигация и создание схемы развертывания EPM: технический документ

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

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

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

GPS-навигация и создание схемы развертывания EPM

В своей последней публикации я рассказывал о применении поэтапного подхода при создании планов развертывания решения для управления крупными проектами (Enterprise Project Management, или EPM) корпорации Майкрософт. Сегодня мы поговорим о создании схемы развертывания EPM в рамках плана проекта.

Если вы пользовались приложением корпорации Майкрософт "Карты Bing", то знаете, что для прокладки маршрута необходимы две вещи: пункт отправления и пункт назначения. Если провести аналогию с развертыванием EPM, то окажется, что и здесь нам нужно нечто подобное:

  1. пункт отправления, определяемый в терминах технологий, процессов и персонала;

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

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

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

Маршрут

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

Карта с маршрутом Сиэтл — Монреаль

Если бы мы просто спросили: "Чего вы хотите?", то в ответ почти наверняка услышали бы описание какого-либо решения. Люди чаще всего отвечают: "Мне нужен вот такой отчет" или "Нашей компании требуется анализ портфеля".

Те, кто занимается разработкой решений, знают, что такие прямолинейные ответы таят в себе риск. Мы учим наших консультантов обращать внимание на случаи, когда клиенты вместо проблемы описывают решение. "Это решение проблемы, — должны ответить они в таком случае, — а не сама проблема. Давайте определим проблему".

Так что мы стараемся не спрашивать: "Чего вы хотите?" Вместо этого на стадии формирования концепции может быть полезен такой вопрос:

"Принятие какого делового решения сейчас невозможно или связано с огромными сложностями, но станет возможным после развертывания этой системы EPM?"

Или такой:

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

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

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

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

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

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

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

Карта с маршрутом Сиэтл — Монреаль

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

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

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

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

Наконец, необходимо провести инвентаризацию технологической платформы. Так как решение EPM корпорации Майкрософт построено на платформе, состоящей из целого ряда технологий, есть вероятность, что некоторые из них уже внедрены. Но также возможно, что организации потребуется обновить часть платформы, чтобы обеспечить работоспособность проектируемого вами решения. SharePoint и SQL Server — это очевидные элементы развертывания Microsoft Office Project Server, но вам также может потребоваться проверить совместимость браузеров (все ли используют последнюю версию Internet Explorer), состояние системы безопасности (будет ли система доступна извне) и развернутую версию SQL Server (используются ли службы OLAP или службы SQL Server Reporting Services). Кроме того, может потребоваться учесть другие системы, с которыми необходимо обеспечить взаимодействие или интеграцию. Как будет осуществляться доступ к этим системам в рабочей среде?

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

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

Пересчет маршрута

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

Карта с маршрутом Сиэтл — Редмонд

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

Конечно, нет.

Четырехчасовое отклонение в рабочем графике отдельного сотрудника в рамках шестимесячного проекта, в котором участвуют десятки людей, — недостаточная причина для изменения всего маршрута. Приступая к любому корпоративному проекту, необходимо установить пороговые значения, влияющие на дальнейшее выполнение работ. В аэрокосмической и оборонной отраслях недавно нашли для этого новый образный термин — "растяжки". Мы можем установить критерии, которые будут указывать на то, что маршрут требует пересчета. Существует ряд типичных метрик, или показателей. Прежде всего, если прогнозируемые затраты на завершение проекта отличаются более чем на X % от исходного бюджета, то это может повлечь за собой пересмотр плана проекта. Затраты могут измеряться в человеко-часах или в денежном выражении. Оба способа эффективны. Возможно, если прогнозируемая дата завершения отличается более чем на X дней от изначально запланированной даты, это также может стать поводом для пересмотра плана проекта.

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

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

  1. Что произошло?

  2. Что мы в итоге имеем? Где мы в настоящий момент находимся?

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

  4. Нужно ли переназначить промежуточные вехи или этапы?

  5. Нужно ли изменить состав рабочей группы?

  6. Нужно ли изменить критерии пересмотра плана проекта?

А вот вопросы, поиск ответов на которые, по нашему опыту, является менее продуктивным:

  • Чья ошибка привела к тому, что мы сбились с маршрута? Кто несет за это ответственность? Чья это вина?

  • Как вернуться на прежний курс, то есть к старому плану?

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

Непогода

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

Страница MSN с прогнозом погоды в Монреале

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

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

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

  1. краткое описание риска;

  2. область или этап проекта, которые могут быть затронуты;

  3. серьезность риска в случае, если критерий выполняется.

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

Пользуйтесь тем, что вы разрабатываете

Вот совет по созданию схемы развертывания, которая может дать отличные результаты: используйте Project Server и решение EPM корпорации Майкрософт для создания схемы развертывания и управления ею. Возможно, это кажется очевидным, но организации поступают так довольно редко, поэтому напоминание не помешает.

Сайт SharePoint со списком конечных результатов проекта

Как-то один старший руководитель рассказал мне, что участники проекта в его организации спросили, не думает ли он, что использовать решение EPM корпорации Майкрософт для развертывания самого решения EPM — это чересчур. "Если бы мы зарабатывали производством реактивных самолетов, мы бы не летали на них на работу", — заявили они. "Вы шутите? — ответил руководитель. — Если бы я мог летать на реактивном самолете на работу, я бы делал это каждый день!"

На самом деле, использовать решение EPM для развертывания системы EPM — это отличная идея.

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

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

  1. Используйте план, составленный по методу набегающей волны, в качестве опубликованного проекта.

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

  2. Управляйте документом, в котором сформулирована концепция, в рабочей области проекта.

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

  3. Включите утвержденные вехи и контрольные точки в перечень конечных результатов в рабочей области проекта.

    Это простой список задач, элементы которого можно связывать с задачами в Project Server. С его помощью можно получить полное представление о проекте. Кроме того, его можно использовать в качестве удобного средства для управления пороговыми значениями с целью выявления "отклонений от курса".

  4. Реализуйте управление изменениями в разделе вопросов в рабочей области проекта.

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

  5. Добавьте в рабочую область проекта сведения о рисках.

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

Цель уже достигнута?

Почти. Осталось совсем немного.

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

  1. Создание схемы развертывания.

    1. Формирование концепции (выбор конечной цели).

    2. Инвентаризация существующих процессов (определение исходного положения).

    3. Инвентаризация имеющегося персонала (определение исходного положения).

    4. Инвентаризация технологий (определение исходного положения).

  2. Развертывание решения EPM для рабочей группы EPM.

  3. Этап 1.

    1. Проектирование.

    2. Настройка и составление документации.

    3. Пилотный этап.

    4. Обучение.

    5. Развертывание.

    6. Анализ результатов этапа 1 и внесение необходимых корректировок в этап 2.

  4. Этап 2.

  5. Этап 3.

  6. Этап 4.

  7. Подведение итогов проекта.

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

Счастливого пути!

Об авторе

Крис Вандерслуис (Chris Vandersluis) — основатель и президент компании HMS Software, расположенной в Монреале, Канада, и являющейся партнером Майкрософт со статусом Microsoft Certified Partner. Он получил степень по экономике в университете Макгилла и имеет более чем 30-летний опыт работы в области автоматизации систем управления проектами. Он много лет является членом Института управления проектами (PMI) и оказывал содействие в основании местных отделений группы Microsoft Project Users Group в Монреале, Торонто и Квебеке. Крис публиковался в таких изданиях, как 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.

×