Как выжить в трудные времена: приоритизация ИТ-инициатив с использованием бизнес-архитектуры

Мартин Сайкс (Martin Sykes),
отдел консалтинга Microsoft (Microsoft Consulting Services)

Брэд Клейтон (Brad Clayton),
отдел консалтинга Microsoft (Microsoft Consulting Services)

Июнь 2009 г.

Краткое содержание.

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

Содержание

Введение

Модель Benefits Dependency Network

Создание диаграммы корпоративных преимуществ

Создание модели функциональных возможностей предприятия

Что такое «возможность»?

Модель Microsoft Services Business Architecture (MSBA)

Сведение воедино модели BDN и модели возможностей

Измерение возможностей

Сопоставление технологий проектирования с проектами модели BDN

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

Выделение ресурсов для отсортированного портфеля проектов и определение сроков

Заключение

Введение

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

Эти методики включают: модель Microsoft Services Business Architecture (MSBA), которая позволяет определить, чтонужно изменить, и модель Benefits Dependency Network (BDN), дающую возможность понять, почемуизменения необходимы. Благодаря этому достигается четкая согласованность с тем, какбудут произведены изменения в проектах. С помощью этих методик можно выявить персонал, процессы и технологии, требующие изменения, и обеспечить четкую согласованность с целями предприятия для получения как финансовой, так и другой выгоды. Многие предприятия использовали данные методики при управлении проектами и приоритизации выполнения проектов.

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

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

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

Рисунок 1. Общее представление процесса
(щелкните рисунок, чтобы увеличить изображение)

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

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

Модель Benefits Dependency Network

Модель Benefits Dependency Network (BDN) обычно занимает одну страницу и связывает ИТ-проекты с изменяемыми бизнес-действиями и причинами, вызвавшими эти изменения. Модель BDN является частью подхода по управлению преимуществами, разработанного в исследовательском центре информационных систем (факультет управления, универси­тет Крэнфилда, Великобритания). За последние 10 лет мы расширили исходную модель, включив в нее временную шкалу.

Рисунок 2. Компоненты BDN (щелкните рисунок, чтобы увеличить изображение)

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

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

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

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

Создание диаграммы корпоративных преимуществ

Rounded Rectangle: Стимулирующие факторы и целиRounded Rectangle: ПреимуществаRounded Rectangle: Затронутая бизнес-функцияRounded Rectangle: Реализуемый проектRounded Rectangle: Технологические инструменты реализацииКак и у многих других клиентов, в банке Contoso имеются сотни ИТ-проектов. Мы начинаем с проектов, которые вносят максимальный вклад в ИТ или деятельность компании, и определяем затрагиваемые ими бизнес-функции и ожидаемые преимущества. Руководствуясь бизнес- и ИТ-стратегией банка Contoso, мы определяем высокоуровневые цели и стимулирующие факторы компании.

Рисунок 3. Фрагмент модели BDN для банка Contoso
(щелкните рисунок, чтобы увеличить изображение)

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

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

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

Создание модели функциональных возможностей предприятия

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

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

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

Что такое «возможность»?

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

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

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

Модель Microsoft Services Business Architecture (MSBA)

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

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

Диаграмма возможностей – это общий язык, на котором ИТ и бизнес могут общаться между собой. Эта диаграмма является надежной основой для выявления и описания служб при определении сервис-ориентированной архитектуры (service-oriented architecture, SOA). В результате исследования предприятий во многих отраслях промышленности корпорация Microsoft выявила, что большинство предприятий демонстрируют пять базовых операционных возможностей, показанных в центре рисунка 4.

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

Рисунок 4. Схема возможностей MSBA
(щелкните рисунок, чтобы увеличить изображение)

На рисунке 4 определены ключевые возможности. На уровне 2 расположена группа возможностей, на уровне 3 и ниже – возможности бизнеса. Это важное различие. Уровни 1 и 2 – это платформа для понимания бизнеса, но только на уровне 3 и ниже можно обсуждать конкретные изменения в проектах и с достаточной точностью определить границы этих изменений.

Цель создания модели возможностей – понять ценность портфеля ИТ-проектов. Это означает, что необходимо оставаться на достаточно высоком уровне моделирования возможностей, чтобы сохранить представление о деятельности всего предприятия и не потеряться в мелочах.

В большинстве случаев соответствие устанавливается только между возможностями проекта на уровне 3, однако иногда это нужно сделать и на уровне 4 – если необходима дополнительная детализация или требуется подчеркнуть специфику одного проекта по сравнению с другим.

Сведение воедино модели BDN и модели возможностей

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

В примере, сформированном по результатам совещания рабочей группы (см. рисунок 2), определено, что проект SmartCheck влияет на бизнес-действие «определение и устранение мошенничества». По мере углубления в модель возможностей мы произвели изменение и связали проект напрямую с возможностью бизнеса уровня 4: «Определение мошенничества». В другом примере рассмотрен проект «OneContoso», цель которого – интегрированное управление счетами клиентов. Для этого проекта мы определили множество затрагиваемых возможностей уровня 4. Эти возможности вместе образуют возможность уровня 3 «Работа с клиентами». Возможности уровня 4 важны для проекта «OneContoso», однако для наших целей мы можем сосредоточить внимание на более высокоуровневой возможности уровня 3 «Работа с клиентами».

Измерение возможностей

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

Существует несколько свойств, часто используемых в работе по определению масштабов проекта:

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

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

Теплокарта банка Contoso

Text Box: 1Contoso BankТеплокарта – это графическое представление диаграммы сущностей, в котором значения свойств используются для определения характеристик сущностей. Например, бизнес-ценность будет представлена цветом границы, а производительность – цветом заливки.

Рисунок 5. Упрощенная теплокарта возможностей банка Contoso
(щелкните рисунок, чтобы увеличить изображение)

На рисунке 5 изображена диаграмма возможностей банка Contoso, на которой цвет заливки обозначает бизнес-ценность, цвет границы – уровень вложений в ИТ.

Два свойства, используемые для анализа портфеля проектов, – это бизнес-ценность, реализуемая за счет улучшения возможности, и связанный с ней уровень вложений в ИТ. Для количественного измерения ценности и затрат используется пятибалльная шкала. Сотрудничая с заинтересованными лицами из ИТ-сферы и сферы бизнеса, мы фиксируем их понимание ценности, которая должна быть получена для каждой возможности как результат работы ИТ, связанных с данной возможностью. На возможность могут влиять несколько проектов, поэтому нас интересует кумулятивное воздействие. Сотрудничая с заинтересованными лицами из ИТ-сферы, мы оцениваем масштаб ИТ‑инвестиций в конкретную возможность. На нее могут влиять несколько проектов, верно и обратное: один проект может затрагивать несколько возможностей. Поэтому мы просим оценить распределение ИТ-инвестиций.

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

На рисунке 5 представлена упрощенная теплокарта (до уровня 2), разработанная для вымышленного банка Contoso. В действительности мы бы углубились только до уров­ня 3 и отобразили бы только те возможности, на которые влияет портфель проектов.

Сопоставление технологий проектирования с проектами модели BDN

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

Мы поставим технологические проекты сразу после бизнес-проектов, поскольку делаем упор на ценность ИТ для бизнеса. Для грамотного формирования структуры следует начать с бизнес-представления.

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

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

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

Располагая полной высокоуровневой моделью BDN и теплокартой, которые показывают потенциальную ценность бизнеса, создаваемую информационными технологиями, мы можем начать анализ портфеля ИТ-проектов. Чтобы проект попал в исходный портфель, он должен удовлетворять базовым требованиям банка к показателям окупаемости. Располагая доступной информацией, мы выполним следующее:

  • Порекомендуем отменить проекты, которые не четко согласованы с целями и преиму­ществами бизнеса.
  • Изменим структуру проектов, сфера влияния которых на одни и те же возможности пересекается, избавившись таким образом от дублирования.
  • Оптимизируем ИТ-проекты так, чтобы бизнес-проекты использовали общие технологии.

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

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

Выделение ресурсов для отсортированного портфеля проектов и определение сроков

После того как будет выделены ресурсы и расставлены проекты согласно их приоритетам, мы разработаем стандартный ИТ-план и дорожную карту. Эта карта имеет множество представлений. На одном из представлений можно показать преимущества проектов, на другом – затрагиваемые возможности.

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

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

Заключение

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

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

Ссылки

  • Peppard, Professor Joe, Professor John Ward, and Professor Elizabeth Daniel. “Managing the Realization of Business Benefits from IT Investments.” MIS Quarterly Executive. Vol. 6, No. 1, 2007, pp. 1–11.
  • Merrifield, Ric. Rethink: A Business Manifesto for Cutting Costs andBoosting Innovation. Upper Saddle River, NJ: FT Press, 2009.
  • Merrifield, Ric, Jack Calhoun, and Dennis Stevens. “The Next Revolution in Productivity.” Harvard Business Review. June 2008.
  • Ward, John, and Joe Peppard. Strategic Planning for InformationSystems. Third ed. Chichester: Wiley, 2008.

Об авторах

Мартин Сайкс (msykes@microsoft.com)– ведущий руководитель проектов по архитек­туре ИТ и планированию в подразделении консалтинга Microsoft. Основное внимание уделяет разработке методик и подходов Microsoft к архитектуре ИТ и планированию.

Брэд Клейтон (bradcla@microsoft.com)– ведущий руководитель проектов по архитек­туре ИТ и планированию в подразделении консалтинга Microsoft. Основное внимание уделяет развитию программы консалтинговых услуг.