Наша следующая тема — это архитектура программы и методы формирования архитектуры. Под архитектурой программы в P2M понимаются структуры, связи между различными проектами-компонентами и методы соединения их в некую органичную структуру. Источником, исходными данными для формирования архитектуры программы является спрофилированная миссия. Мы уже многие вещи знаем о программе: мы знаем о целях, мы знаем о задачах, которые нам придется решать, мы поняли, какие показатели мы будем использовать для оценки продвижения программы, мы запланировали определенные сценарии, обсудили их, рассмотрели альтернативные варианты — все это теперь нужно соединить в гармоничном единстве. Что должна обеспечивать архитектура программы? С одной стороны, должна быть рациональная структура. Проектов много, эти проекты связаны между собой, некоторые задачи мы должны научиться распределять по разным проектам, какие-то задачи мы должны объединять в один проект. Рациональная структура проектов является как раз ключевым элементом архитектуры программы. Вторым элементом, который необходимо учитывать при формировании архитектуры, являются модель управления и структура управления программой. Мы должны распределить функции управления между заинтересованными сторонами, мы должны создать систему управления этой программой. Система должна обеспечивать то, что называется рациональной управляемостью: она не должна быть чрезмерно забюрократизирована, но тем не менее все необходимые действия должны быть в этой системе описаны. С другой стороны, архитектура программы должна учитывать несколько важных факторов. Когда мы говорим об управлении, мы должны понимать, что все заинтересованные стороны, так или иначе влияющие на успех этой программы, должны привлекаться к управлению этой программы, к участию в управлении этой программы. Мы должны понимать, как распределены финансовые потоки. Мы должны понимать, каким образом и в какие моменты мы будем рассматривать варианты перехода с одного сценария на другой, каковы иные ответные действия на изменения во внешней и внутренней среде организации. Все это и дает нам совокупность проектов, совокупность проектов, соединенных различными сценариями, и при этом содержание каждого проекта определяется теми задачами, которые мы включили в состав нашей программы. При проектировании архитектуры программы действительно очень важным моментом является определение взаимосвязей между различными проектами. Здесь нужно отметить три различных модели, проектных модели, которые P2M рекомендует, и даже настойчиво рекомендует, надо сказать, считает обязательными при исполнении инновационной программы. Таких модели три, я о них достаточно подробно постараюсь рассказать: модель схематичная, модель системная и модель сервисная. Начну я со второй позиции, системная модель — это традиционная проектная модель, модель, возможно, оптимизированная, но об этой модели те, кто занимается профессионально управлением проектами, хорошо знают, они хорошо с ней знакомы. Эта модель дает понимание того, как следует управлять, чтобы лучше реализовать проект. Вот такая простая формулировка. Туда входят управление содержанием, управление по временным параметрам, управление стоимостью проекта, управление рисками проекта и так далее по всем областям знаний управления проектами. Если мы от этой модели поднимемся наверх, мы попадем как раз в зону формирования миссии, это то, что называется схематичная, или схематическая, модель. Модель, которая позволяет перенести в программу понимание владельцем ценности инновации. Здесь традиционные функции управления проектами расширяются вверх. Мы помним это по башне P2M — это то, что находится в верхушке пирамиды, и именно эти функции позволяют обеспечить правильные формулировки новых ценностей, которые должны быть созданы в нашей программе. И если мы пойдем от системной модели вниз, если мы перейдем к следующему этапу освоения того, что создано в нашей программе, то есть продукт создан, мы начинаем его эксплуатировать, и здесь начинает работать сервисная модель — модель, связанная с открытием новых возможностей и получением новых ценностей от того продукта, который мы уже создали. Мы должны оценить, полностью ли этот продукт соответствует тому, что мы изначально планировали, не отклоняет ли нас то, что мы сделали в рамках законченного проекта, от цели, от нашей целевой бизнес-модели. Возможно, мы можем улучшить и усилить те эффекты, которых мы можем добиться в нашей программе. Таким образом мы получаем расширение функций управления проектами вниз, и это расширение дает нам возможность попробовать, по крайней мере, максимизировать ценность, создаваемую программой в целом или отдельными проектами. Все эти модели связаны между собой, и если говорить о логике совместного использования этих моделей, то она вот самая, наверное, простая и понятная логика. Она выглядит как некий цикл, когда мы на уровне схематичной модели закладываем определенное видение того, что мы должны получить, представление о результатах, дальше на уровне системной модели мы эти результаты получаем, на уровне сервисной модели мы эти результаты опробуем на практике, изучаем, насколько мы достигли желаемых целей и в какой степени мы решили поставленные задачи, и в зависимости от этого мы возвращаемся к схематической модели и изменяем, возможно, изменяем эту модель. Возможно, меняем сценарии, возможно, добавляем какие-то, дополняем какими-то задачами, возможно, меняем саму архитектуру управления программы. У нас могут появиться новые задачи, у нас могут появиться новые участники — возможно, нам придется изменить и систему управления нашей программой. Если сформулировать теперь все, что мы говорили об управлении программой, мы приходим к понятию интеграции, управления интеграцией программы. Вообще, есть, по мнению авторов стандарта, есть всего две задачи управления программой. Первая задача — ту, что я назвал, управление интеграционной деятельностью, управление интеграцией программы. Вторая задача — управление сообществом программы. Управление сообществом — об этой теме мы будем говорить позже, а вот для того чтобы сформулировать, в чем состоит управление интеграцией, мы уже полностью готовы, весь этот материал уже в нашем распоряжении. На входе у нас — миссия программы. Здесь очень важна еще одна, я бы сказал, основополагающая позиция авторов стандарта, они называют ее «растяжение» миссии для максимизации ценности. Мы должны на каждом этапе реализации программы, в каждом проекте программы найти возможности для увеличения ценности этой программы для будущих владельцев этих результатов. И растяжение миссии достигается с помощью четырех основных инструментов. Первый инструмент — принцип «замысла с нуля». Мы не должны идти на компромисс, мы должны зафиксировать то, что мы хотим получить, и единственная возможность, которую мы должны себе оставить — это растяжение миссии, это улучшение продукта, который мы создаем, или увеличение количества продукта. Принцип гибкости к изменениям. Очень важный принцип, здесь у нас есть понятие неопределенности, здесь у нас есть сценарии, и мы должны быть готовы переключаться с одного сценария на другой, если того потребуют внутренние или внешние обстоятельства. Третий принцип — принцип совместной компетенции. Я уже сказал о том, что здесь мы пока еще не готовы к обсуждению, это вопрос управления сообществом. Тема, безусловно, очень важная, и мы о ней будем подробно говорить чуть позже. И наконец, последний принцип — постоянной оценки ценности. Мы с помощью той самой системы сбалансированных показателей, Program ScoreCard, должны и в начале проекта, и в конце проекта, и по мере реализации проектов программы оценивать, в какой степени мы достигаем поставленных перед собой... мы решаем поставленные перед собой задачи и достигаем показатели. Если соединить все это в виде метафоры, а авторы стандарта P2M очень любят различные метафоры и настаивают на их применении, мы получаем вот такую дорожную карту управления программой, в которой соединены основным, базовым потоком управления программой те основные элементы, о которых мы с вами уже поговорили. Есть предварительная оценка миссии, в которой формируется общее видение, разнообразие окружения, расширяемость, сложность, уровень неопределенности определяется программы. Дальше, на последующих шагах мы формируем стратегию реализации программы, профилируем миссию, мы управляем архитектурой программы, определяем дизайн и состав проектов программы. Все это происходит на фоне непрерывной оценки ценности с помощью индикаторов ценности, и в конце концов это приводит нас к тому результату, ради которого программа и была затеяна, мы получаем ценность программы в том виде и в том объеме, как планировали изначально. Мне хотелось бы познакомить вас с несколькими примерами того, как формулируются дорожные карты, и к этой теме мы перейдем с вами на следующей встрече.
