Преодоление периода полураспада (T½) — правильная эксплуатация решения для управления портфелем проектов после внедрения: технический документ

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

Чтобы загрузить этот технический документ в формате Word, воспользуйтесь ссылкой Преодоление периода полураспада (T½) — правильная эксплуатация решения для управления портфелем проектов после внедрения: технический документ.

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

Преодоление периода полураспада (T½) — правильная эксплуатация решения для управления портфелем проектов после внедрения

Введение

В радиофизике период полураспада квантовомеханической системы (частицы, ядра, атома, энергетического уровня и т. д.) — это время T½, в течение которого система распадается в примерном отношении 1/2 (см.: https://ru.wikipedia.org/wiki/Период_полураспада).

Каким же образом применить это понятие к только что установленному вами абсолютно новому решению по управлению портфелем проектов (Project Portfolio Management, или PPM)? Сходство этого решения с упомянутыми выше системами заключается в том, что у решения есть дата истечения срока действия. Если вы не выделите время для того, чтобы спланировать, разработать и внедрить процедуру управления решением PPM, то со стопроцентной вероятностью вскоре обнаружите устаревшие данные, неудачные изменения структуры, процессы, не соответствующие фактическим процессам в организации, и многие другие отрицательные явления. В точности как автомобиль, никогда не проходивший обслуживания, ваше решение вскоре перестанет давать ожидаемые от него результаты, т. е. обеспечивать рентабельность инвестиций. Пользователи утратят энтузиазм и либо прекратят использовать это решение, либо начнут активно высказываться в пользу другого продукта.

Цель этой статьи — обсудить платформу для создания модели управления решением PPM. Кроме того, в ней приведен пример плана управления, который можно использовать в качестве отправной точки для создания стратегии управления.

Что и почему

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

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

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

Области управления

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

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

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

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

Четыре основных области решения PPM, требующих изменений: сведения, дизайн, инфраструктура и процесс.

Управление информацией

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

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

Управление структурой

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

Управление структурой — это план управления изменениями, которые затрагивают всю структуру решения PPM.

Управление процессом

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

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

Изменениями такого типа необходимо управлять с помощью стандартного набора правил, определенного в рамках управления процессом.

Управление инфраструктурой

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

  • установка обычных или накопительных пакетов обновления;

  • установка новых надстроек или приложений;

  • обновление инфраструктуры (добавление серверов приложений, веб-серверов и т. п.) для решения проблем с производительностью;

  • изменения в инфраструктуре в связи с изменениями других приложений в организации (например, в связи с виртуализацией всех серверов).

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

Ключевые вопросы

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

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

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

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

Группа управления

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

Ниже описан один из подходов к формированию структуры группы.

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

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

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

Другие ключевые элементы

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

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

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

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

Процесс

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

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

Заключение

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

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

  • План управления не должен представлять собой фолиант с множеством непонятных терминов, написанный на языке, которым в обычной жизни никто не пользуется. Это может быть простой лист Excel с краткими ответами на основные вопросы (см. раздел "Ключевые вопросы").

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

  • План управления должен быть прост для реализации и хорошо интегрирован с существующими в организации процессами. Нет необходимости повторно изобретать колесо.

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

Об авторе

Прасанна Адави (Prasanna Adavi) — старший консультант и инструктор по управлению корпоративными проектами, обладатель сертификатов корпорации Майкрософт (PMP, MCTS, MCITP, MCT); специализируется по платформам Microsoft Project, Microsoft Project Server и Microsoft SharePoint. Его основная деятельность — разработка и внедрение бизнес-решений, помогающих организациям добиться максимальной рентабельности своих инвестиций.

Кроме того, он обладает большим опытом ведения проектов от начала до конца в различных сферах деятельности и сегментах рынка, включая ИТ, системы планирования ресурсов предприятия (SAP), производство, разработку приложений, автомобильную отрасль и креативные компании. Он регулярно выступает с докладами на различных конференциях по Project Server, SharePoint и управлению корпоративными проектами в разных городах и постоянно участвует в деятельности сообщества SharePoint и EPM.

Прасанна Адави ведет блог (http://www.prasannaadavi.com), а также подкаст (http://www.msprojectpodcast.com), посвященный в основном решениям Microsoft Project и Project Server (новые выпуски выходят каждые две недели). Прасанна — старший консультант в компании EPMA (http://www.epmainc.com).

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

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

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

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

×