Архитектура и стратегия: "инь" и "янь" информационных технологий предприятия

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

Л. Толстой. "Война и мир"

Осмелимся сделать следующее заключение об отечественном опыте и практике использования слов "стратегия" и "архитектура". Складывается впечатление, что общей является следующая ситуация: в России и бизнес-руководители, и руководители в области ИТ чаще мыслят в терминах "стратегий", т.е. "бизнес-стратегий" и "ИТ-стратегий" соответственно. Особенно это характерно для области государственной информатизации. За последние десять с лишним лет под ее эгидой было опубликовано несколько различных "стратегий" (под названием "Концепция" или "Cистемный проект") и ни одного публичного документа с описанием архитектуры; да и управление портфелем проектов часто фактически заключается в формировании списков лотов для тендеров.

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

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

Рис. 1.1.  Отечественная и мировая практика использования понятий "стратегия" и "архитектура"

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

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

Рис. 1.2.  Связи между Архитектурой, Стратегией и Портфелем проектов

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

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

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

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

В самом общем виде стратегия предполагает наличие видения, цели и определение ограниченного набора опций (путей, способов) ее достижения [7.1]. Стратегия, таким образом, накладывает ограничения на способы достижения видения или целей. Видение или цель являются необходимыми, но не достаточными атрибутами стратегии. Цель, сама по себе, может быть ничем не ограничена и предполагает бесчисленное множество путей ее достижения. Без ограничений, без ограниченного набора способов достижения эта цель, видение остаются удаленными миражами, которые не могут быть достигнуты какими-либо конкретными путями.

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

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

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

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

Трехуровневая модель определения компонент стратегии включает в себя:

описание конечного состояния (видение, цель);описание ограниченного набора способов достижения цели (основная стратегия);шаги к достижению цели (тактика или конкретные проекты).

Эти элементы определяют структуру стратегии. Но требуется еще одно измерение для того, чтобы выработать и реализовать успешную стратегию: это ресурсы, способности, потенциал, ключевая область компетенции организации (все то, что вмещает в себя одно английское слово – capabilities). Хорошее изложение концептуальных основ стратегии приведено в уже упоминавшейся книге Д. Коллинза [7.2].

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


Рис. 1.3.  Архитектура, стратегия и тактика

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

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

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

Два аспекта деятельности, связанной с информационными технологиями

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

Для лучшего понимания контекста, в котором должны разрабатываться стратегия и архитектура предприятия, еще раз обратим внимание на фундаментальное разделение двух аспектов деятельности ИТ-служб: создание и управление приложениями (прикладными системами) и эксплуатация инфраструктуры. [7.1]. Внимание, которое мы уделяем этому разделению, вызвано тем, что, как мы покажем ниже, стратегия и архитектура ИТ в равной степени имеют отношение как к основной деятельности организации (бизнесу), так и к технологическим аспектам как таковым. Соответственно, к этим аспектам управления ИТ предъявляются разные требования.

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

приложения определяют то, как выполняется работа, поэтому разработка приложений тесно связана с основным бизнесом компании или деятельностью государственной организации, а знание приложений – это, прежде всего, понимание бизнес-процессов;эксплуатация инфраструктуры – деятельность, относительно слабо связанная с ключевыми функциями (бизнесом) организации, сфокусированная в основном на технологиях. Грубо говоря, не требуется знать бизнес-процессы компании для того, чтобы понимать, что такое Web, Windows или Unix.

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

приложения как элемент стратегии ИТ – это зона ответственности бизнеса. Основой функционирования организации являются бизнес-процессы, которые поддерживаются прикладными системами. Руководство компании должно оценивать стратегию в области прикладных систем с точки зрения качества и результативности (effectiveness) поддержки ключевых функций;эксплуатация инфраструктуры сфокусирована на сегодняшних, ежедневных проблемах. Бизнес-руководство оценивает стратегию в области ИТ-инфраструктуры с точки зрения эффективности (efficiency – максимальная отдача при минимальных затратах).

Как уже отмечалось, двумя ключевыми элементами поддержки разработки стратегии ИТ являются:

ИТ-архитектура. Подчеркнем, что это единственный "технический" аспект ИТ, который должен пониматься и в какой-то степени контролироваться бизнес-руководителями. Таким образом, им не обязательно вникать в конкретные возможности приложений или параметры закупаемых серверов.Финансовые и альтернативные инструменты. Стратегия – это всегда принятие решений. Чисто финансовые инструменты (ROI, ROA), а также "смешанные" типа TVO (Total Value of Opportunities – ценность возможностей для бизнеса) – это тот "язык", который должен использоваться для поддержки принятия решений. Естественно, что он должен быть определен и согласован до того, как с его помощью будут отбираться проекты для реализации; иначе потом может возникнуть сильное желание выбора постфактум такого инструмента, с помощью которого можно "обосновать" принятие "нужного" решения.

Контекст стратегии ИТ

На самом деле, процесс выработки любой стратегии не претерпел существенных изменений с тех пор, как Майкл Портер написал свою книгу "Конкурентная стратегия" в 1980 году [7.3]. Если говорить об этом процессе в контексте информационных технологий, то он состоит из последовательных этапов, которые начинаются со сбора бизнес-информации, информации о состоянии дел в области ИТ и, в конечном счете, в формулировке, выполнении списка ИТ-проектов и обновлении стратегии с учетом новой информации так, как показано на рис. 1.4.

Рис. 1.4.  Процесс разработки стратегии ИТ по Giga

Существует много вариаций тех методик, которые используются на этапах процесса: это и квази-финансовые инструменты, такие как управление портфелем прикладных систем, и инструменты, которые пришли из области маркетинга, такие как SWOT-анализ (SWOT – Strengths, Weaknesses, Opportunities and Threats), т.е. анализ сильных и слабых сторон, а также возможностей и рисков.

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

Рис. 1.5.  Разработка стратегии ИТ и реализация проектов

И если общие черты процесса выработки и использования стратегии ИТ понятны, то само понятие "стратегия ИТ" требует уточнения. С учетом приведенных нами выше общих обсуждений проблемы, можно предложить модель того, что является стратегией информационных технологий как с точки зрения ее основных элементов (содержания), так и с точки зрения организации процесса формулировки стратегии ([7.1], [7.5], [7.6]). Рисунок 1.6 отражает основные элементы модели стратегии информационных технологий.

Рис. 1.6.  Модель стратегии информационных технологий

Таким образом, мы имеем следующее.

Основой обсуждения и разработки стратегии ИТ является бизнес-стратегия независимо от того, существует ли она в явно сформулированной форме или нет (мы рассмотрим далее пути решения этой проблемы, когда отсутствует явно сформулированная бизнес-стратегия).

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

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

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

В соответствии с рекомендациями Gartner, вопросы планирования развития ИТ-систем организации целесообразно разделять на 3 раздельных документа – соответственно "ИТ-стратегия", "ИТ-архитектура" и "План реализации проектов". Разработка этих документов производится на основе формирования и анализа расхождения между целевым состоянием систем предприятия (т.е. состояния, при котором ИТ обеспечивают требования со стороны бизнеса с учетом перспектив его развития) и существующим состоянием ИТ-систем.

Как эта модель соотносится с российской действительностью?

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

Другие различные варианты состава ИТ-стратегии и описания подходов к ее разработке приводятся, в частности, в докладах на конференциях ФОСТАС (http://www.fostas.ru).

Вопросам разработки ИТ-стратегии посвящена статья А. Михайлова [7.8]. В ней дан краткий обзор зарубежной практики формирования ИТ-стратегии как способа перемещения компании (включая информационные системы, ИТ-инфраструктуру и ИТ-службы управления ею) из текущего состояния в требуемое будущее состояние. При этом делается попытка соотнесения этого опыта с отечественной практикой разработки автоматизированных систем согласно ГОСТам.

В статье [7.9], подготовленной на основе доклада А. Баркина из компании A.T. Kearney, акцентируется внимание на разработке первой для предприятия ИТ-стратегии. Такая ситуация, на самом деле, является весьма типичной для российских предприятий, так как многие из них только сейчас осознают необходимость ухода от сегодняшней, во многом стихийной, практики развития ИТ. Тут сказываются и короткий срок существования новой экономики, и прошедшие события финансового кризиса 1998 года, и вечная ограниченность средств, выделяемых на автоматизацию. Соответственно, первый шаг очень часто сопровождается возможными ошибками. Этот аспект мы рассмотрим более подробно в лекции 2. C другой стороны, как указано в данной статье, именно первопроходцу иногда бывает легче "заложить грамотно спроектированный фундамент и построить прочную, но открытую к эволюции" информационную систему – здесь (пока!) не давит груз прошлых ошибок и скептическое отношение бизнес-подразделений. Как здесь не вспомнить шутку о том, что "богу было легко создать мир за семь дней, поскольку отсутствовали унаследованные системы".

К сожалению, более-менее полная статистика по наличию ИТ-стратегии на российских предприятиях отсутствует. По данным опроса [7.10] 2003 года руководителей ИТ-служб предприятий по производству и торговле металлопродукцией, только 18% с уверенностью отметили наличие ИТ-стратегии, а половина сообщили, что она скорее имеется, чем не имеется. Около половины респондентов отметили, что руководство компании считает ИТ-стратегию чисто техническим вопросом. А по результатам опроса участников 3-го ежегодного всероссийского форума пользователей ERP-систем, организованного компанией TopS Business Integrator в феврале 2005 года, у 54% участников ИТ-стратегия уже существует, а еще 34% планируют ее разработку в ближайшее время. Это является косвенным свидетельством того, что информационные системы, обслуживающие бизнес наших предприятий, уже достигают определенной степени зрелости.

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

Проблемы, связанные с процессом разработки стратегии ИТ

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

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

Процесс может быть очень продолжительным. Разработка стратегии ИТ может занять много времени и потребовать усилий большого количества людей. Для крупных организаций он может занять более полугода. В результате возможна ситуация, когда многие рекомендации, на основе которых отбирались проекты для включения в стратегический план, могут потерять свою актуальность. Кроме того, процесс планирования не выглядит как "реальная работа" для большинства участников, поскольку не является частью их ежедневных обязанностей, за которые они получают зарплату. Участие в процессе планирования не всегда рассматривается как оптимальный путь развития карьеры: часто он означает отсутствие оперативных обязанностей, небольшие возможности по практической реализации планов и отсутствие в подчинении большого количества людей – все те атрибуты, с которыми ассоциируется понятие "статуса" в организации.Стратегический план является статическим документом. И хотя мы подчеркивали важность процесса обновления стратегии ИТ, это не всегда легко реализуется на практике. Характерный "период полураспада" большинства стратегических планов в области ИТ составляет около 6 месяцев, т.е. за полгода половина положений стратегии может потерять свою актуальность в результате действия таких факторов, как изменения в бизнес-среде, слияния и реорганизации, изменения в технологиях, новые приоритеты бизнеса. Кроме того, важно помнить, что стратегические планы связаны с конкретными людьми, а как показывает статистика, скорость обновления в рядах высшего руководства компаний составляет 20-25% в год. Все это еще раз подчеркивает важность выработки организованного процесса обновления стратегии ИТ.Процесс разработки стратегии является крайне политизированным. Поскольку решения в области стратегии являются во многом субъективными, разработка стратегии ИТ становится политическим ритуалом. Как принимать объективные решения о сравнении между собой нескольких альтернативных проектов в условиях высокой степени неопределенности? Всегда есть риск "поддаться на уговоры" наиболее харизматичного "спонсора" потенциального проекта, вместо использования объективных критериев.Процесс является достаточно запутанным и сложным. Выработка стратегии требует от людей ориентации на незнакомой территории. Достижение согласия даже по таким простым вещам как термины, может создавать проблемы. Что, например, включать в понятие "стоимость проекта": все затраты на работу персонала, затраты на сопровождение (в течение какого промежутка времени?), какова ставка-ориентир для инвестиционных проектов в области ИТ и т.п.Планирование и практическая реализация – часто слабо связанные вещи. Хотя само участие в процессе выработки стратегических планов увеличивает степень принятия этого плана людьми в качестве руководства к действию, вовлечение людей в процесс планирования – непростая задача: у них всегда мало времени на планирование.

Процесс, порядок разработки и управления стратегией ИТ

Используя рассмотренные нами выше основные элементы стратегии ИТ в качестве "строительных блоков", можно определить основные этапы процесса разработки ИТ-стратегии [7.12], [7.13].

Gartner предлагает следующий подход к составным элементам (блокам) ИТ-стратегии и определяет 9 этапов реализации:

Согласование понимания требований бизнеса к ИТ (понимание направлений развития бизнеса).Определение процессов управления и контроля, выбор финансовых критериев/инструментов для принятия решений и сравнительного анализа вариантов стратегии.Определение будущего состояния архитектуры предприятия (высокоуровневое описание).Анализ текущего состояния ИТ и оценка вариантов реализаций с учетом существующих ограничений, накладываемых имеющейся инфраструктурой ИТ.Разработка стратегии развития/изменения приложений. Применение знаний, полученных на предыдущих этапах.Формирование стратегии развития процессов и операций управления ИТ-ресурсами. Стратегическим направлением здесь может являться переход к сервисной модели предоставления ИТ-услуг. Эти аспекты рассмотрены далее в этой лекции и лекциях 4, 5.Определение стратегии и задач по развитию необходимых кадровых ИТ-ресурсов и позиционированию аутсорсинга.Подготовка документа с описанием стратегии ИТ и представление результатов для формального обсуждения.Организация управленческого процесса поддержания стратегии в актуальном состоянии.

Этот процесс показан на рис. 1.7. Рисунок подробно отражает аспекты, связанные с управлением стратегией, и их связь с тактическими вопросами. Сами вопросы тактики и управления на тактическом уровне (например, управление проектами) мы здесь не рассматриваем. Заметим лишь, что это отдельная, достаточно обширная, самостоятельная дисциплина.

Рис. 1.7.  Модель процесса управления стратегией ИТ

Стрелки в левой части этого рисунка отражают факторы (движущие силы), влияющие на стратегию. Это те компоненты, которые составляют суть содержания стратегии. Факторы влияния действуют на стратегию посредством процесса управления стратегией ИТ, который представлен в центре. Стрелки в правой части рисунка, идущие в обратную сторону, представляют элементы контроля, т.е. это обратная связь, которая обеспечивает внесение изменений в стратегию. Рассмотрим более подробно эти элементы.

Факторы влияния:

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

Элементы контроля:

существует много методов контроля выполнения портфеля проектов. Для этого создано специализированное программное обеспечение, которое, обычно, использует метафору "приборной панели" для отражения состояния дел с проектами (так называемая "project dashboard");схема оплаты за предоставляемые услуги (например, схема, предполагающая отчисления из бюджета подразделений – chargeback) позволяет отслеживать реальные затраты и исполнение бюджета;результатом является информация о проектах, финансовая и нефинансовая, которая может использоваться, например, в системе сбалансированных показателей;система сбалансированных показателей служит инструментом управления, который позволяет отслеживать и управлять достижением целей, стоящих перед предприятием (особенно стратегических целей) и теми работами, которые рассматриваются как критически важные;с учетом этой информации, стратегия подвергается пересмотру для того, чтобы отражать те новые моменты, которые стали очевидными по ходу ее реализации.

Если будут пропущены какие-либо элементы этого процесса, то стратегии в лучшем случае будут малоэффективными, а в худшем – нереализуемыми.

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

Связь бизнес-стратегии и стратегии ИТ

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

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

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

прибыль (94% руководителей указали это как важный фактор по их собственному убеждению и 90% как важный фактор с точки зрения инвесторов).оборот (87% и 81% соответственно).корпоративная стратегия (85% и 78% соответственно).

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

Опросы, которые проводила Gartner [7.11], показывают, что наиболее часто сформулированными бизнес-стратегиями являются следующие: улучшение продуктов (31%), рост через приобретение других бизнесов (24%), фокус на клиентах (22%), уменьшение расходов (22%). К сожалению, ни одна из этих "стратегий" не представляет особой ценности с точки зрения формирования стратегии информационных технологий; а у 30% организаций бизнес-стратегии отсутствовали вообще.

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

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

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

Почему бизнес-стратегия важна для стратегии ИТ?

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

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

Итак:

для формулирования ИТ-стратегии нужно знать бизнес-стратегию;ИТ-служба не вправе навязывать организации бизнес-стратегию;ИТ-служба должна определять стратегию ИТ в рамках и в соответствии с основными элементами бизнес-стратегии.

Возможная структура документа, описывающего стратегию ИТ

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

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

Таблица 1.1. Возможная структура документа "Стратегия ИТ предприятия"

ВведениеЦелевое состояние информационных системЦелевая система управления ИТ-ресурсамиПлан перехода

Цели работы, ограничения и подход	Здесь кратко формулируется назначение документа, определяется его позиционирование для работы ИТ-службы и бизнес-подразделений, приводятся ссылки на другие документы (описание архитектуры, план проектов)
Связь со стратегией бизнеса	Здесь описываются внешние и внутренние условия, которые определяют направления развития бизнеса, цели бизнеса и основные инициативы. На основе бизнес-стратегии развития компании формулируются основные задачи информационных систем (что требуется) и ИТ-службы (как делать). Определяется позиционирование ИТ для бизнеса организации: например, является ли она конкурентным преимуществом или центром затрат. Здесь можно подчеркнуть роль перспективных информационных технологий для развития существующего бизнеса или создания новых бизнес-направлений
Существующая организация дел в области ИТ	Приводится краткое неформальное описание "верхних уровней" Архитектуры предприятия. Это могут быть уровни, связанные с бизнес-архитектурой и портфелем прикладных систем, или два верхних уровня модели Gartner. Кратко формулируется оценка соответствия существующего состояния архитектуры требованиям бизнеса, основные проблемы ИТ. Может быть приведено резюме сравнения с конкурентами или с лучшими практиками
Целевая архитектура предприятия (позиционирование/оценка/важность)	Для основных направлений бизнеса приводится резюме по развитию, сохранению или замене соответствующих прикладных систем. Этот раздел не предназначен для описания технических деталей
Интеграция	Резюме по организации взаимодействия с внешними системами (поставщики, клиенты), а также приложений между собой, созданию порталов и хранилищ данных и т.п.
Инфраструктура	При необходимости развития инфраструктуры приводится краткая характеристика направлений развития (модернизация серверов, создание глобальных сетей и т.п.)
Целевая система управления ИТ-ресурсами	Основные направления совершенствования процессов управления ИТ, оценки качества и целевые показатели работы ИТ
Организационные изменения	Возможные изменения в структуре управления ИТ, роль CIO. Организация стратегического управления ИТ
Взаимодействие	Реализация модели взаимодействия между ИТ- и бизнес-подразделениями
Сорсинг	Стратегия выбора исполнителей и поставщиков услуг. Развитие персонала внутренней ИТ-службы
Финансирование	Источники и порядок финансирования, используемые финансовые инструменты, организация принятия решений
Укрупненный план перехода к целевой архитектуре информационных систем	Интегральные характеристики ИТ-бюджета и списка проектов. Принципы выбора/приоритезации проектов и инструменты для их оценки
Варианты и риски	Возможные варианты стратегии в зависимости от объемов финансирования и вариантов развития бизнеса, анализ рисков. Оценка готовности организации к реализации данной стратегии
Выбор проектов	Классификация и список важнейших проектов на ближайшие 1-3 года, сгруппированных по категориям. Цель дать краткое неформальное описание в рамках одного сводного документа (цели, задачи, сроки), а также подчеркнуть вопросы взаимозависимости проектов

Финансовые инструменты принятия

Статьи затрат. Все затраты (а также, изредка, прямые доходы), связанные с использованием информационных технологий на предприятии, должны быть разнесены по статьям, которые, в свою очередь, должны быть связаны с центрами затрат (cost center). Это обеспечивает инструменты контроля затрат, что является основой для будущих управленческих решений. Традиционный подход состоит в разнесении затрат по категориям, таким как: основные фонды (аппаратное и соответствующее программное обеспечение различных типов: серверы, рабочие станции, мобильные системы и пр.), амортизация, аренда и лизинг, поддержка и сопровождение, телекоммуникации, внешние услуги, расходные материалы. Более новый подход связан с организацией деятельности ИТ-департамента как сервисной организации, т.е. с разнесением затрат по типам активностей, например, поддержка работы прикладных систем, Help Desk, обслуживание рабочих станций. Для этого необходимо создание некоторого "виртуального уровня" разнесения затрат поверх традиционных организационных структур. Но преимуществом является возможность сопоставления внутренних цен департамента ИТ с ценами внешних поставщиков аналогичных ИТ-услуг. Например: насколько стоимость обслуживания рабочих станций сотрудников организации собственным департаментом ИТ сравнима со стоимостью той же услуги при использовании аутсорсинга? При этом для сравнения необходимо увеличивать внутренние цены на 5-10%, отражая скрытые накладные расходы, связанные с управлением.Методы оценки стоимости и цены. Эти методы дополняют статьи затрат. Суть состоит в том, чтобы, пусть не со 100-процентной точностью, но в достаточной мере адекватно определять стоимость ИТ-сервисов, которые департамент ИТ предоставляет бизнес-подразделениям. Опять-таки в основе традиционного подхода лежат функционально-организационные структуры и центры затрат. Новый подход состоит в более гранулированной идентификации стоимости ИТ-сервисов. Очевидно, что при этом стоимость ИТ-сервисов напрямую связана с уровнем услуги: так, стоимости обеспечения доступности прикладной системы на уровне 99% или 95% существенно различаются, так же как и гарантия времени отработки запроса на установку стандартного ПО на компьютер сотрудника в один день или одну рабочую неделю.Методы оценки инвестиций. Запросы на реализацию определенных ИТ-проектов приходят из самых разных "уголков" организации и имеют разные уровни финансового обеспечения. Хорошей практикой является разделение этих запросов на две группы: небольшое количество крупных, стратегических проектов и большое количество небольших проектов, которые связаны с изменениями и улучшениями, относящимися к имеющимся бизнес-процессам и системам. В принципе, финансовые инструменты в обоих случаях могут использоваться одни и те же, но для маленьких проектов требуется более оперативная схема принятия решений.

Если говорить подробнее про методы оценки инвестиций, то можно выделить три группы методов:

Традиционные финансовые инструменты: период возврата инвестиций; будущие поступления средств, приведенные в оценке настоящего времени (DCF – Discounted Cash Flow); норма прибыли (IRR – Internal Rate of Return); возврат на инвестиции (ROI – Return on investment); экономическая добавленная стоимость (EVA – Economic value Added) и пр.;Новые финансовые инструменты. К этой категории относятся такие инструменты, как общая ценность для бизнеса (TVO – Total Value of Opportunity, см. лекцию 5), оценка реальных опций;Нефинансовые инструменты принятия решений: сценарный анализ, формальные методы анализа решений.

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

Как быть, если в организации отсутствует явно сформулированная бизнес-стратегия

Выше упоминалось, что разработка ИТ-стратегии должна базироваться на бизнес-стратегии предприятия. В этом плане идеальным будет такой случай, когда в бизнес-стратегии четко описаны все аспекты в понятных терминах. Например, "...в настоящее время у компании 3 магазина в городе N. До конца года планируется увеличить число магазинов до 5, охватив города M и L, а также организовать оформление предварительных заказов через Интернет и довести долю электронных заказов до 15%. Владельцы предприятия готовы осуществлять необходимые инвестиции в ИТ в размере до $500 тыс." В этом случае разработка ИТ-стратегии представляет собой задачу с четко определенными начальными условиями.

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

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

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

Означает ли, что в такой ситуации на разработке ИТ-стратегии нужно "поставить крест"? В работах [7.15], [7.16] предлагаются возможные альтернативные решения. При этом ИТ-специалистам вряд ли стоит "брать на себя слишком много" и пытаться самим сформулировать бизнес-стратегию. Такая инициатива с большой вероятностью окажется неудачной из-за наличия "кастовых" разделений в организации. Дело в том, что многие бизнес-менеджеры во многих случаях на деле не способны сформулировать полноценную бизнес-стратегию, которая выходила бы за рамки общих утверждений типа "увеличим долю рынка на 20%". В этих условиях проект разработки стратегии может выявить их относительную некомпетентность в этом вопросе, так что они объективно будут заинтересованы в провале такого проекта.

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

Такая модель должна учитывать следующие факторы:

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

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

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

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

Среди лучших практик по организации разработки ИТ-стратегии ведущие компании отмечают следующие:

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



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

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

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

Среди лучших практик по организации разработки ИТ-стратегии ведущие компании отмечают следующие:

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

Модель для идентификации важных с точки зрения ИТ элементов бизнес-стратегии

Независимо от того, есть ли в организации явно сформулированная бизнес-стратегия или нет, для понимания сути влияния бизнес-стратегии на стратегию ИТ важно дать ответ на два вопроса:

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

На самом деле, в соответствии с Gartner, количество элементов, определяющих ИТ-стратегию, может быть уменьшено до пяти областей:

ИТ-инфраструктура. Все компоненты ИТ (аппаратное и программное обеспечение и комплектующие, сети), необходимые для обеспечения среды выполнения бизнес-процессов предприятия.ИТ-сервисы (эксплуатация). Как департамент ИТ обеспечит доступность ИТ-среды, какие услуги бизнес-подразделения получают от департамента ИТ на ежедневной основе. Наиболее общим определением ИТ-услуг для бизнес-подразделений является Соглашение об уровне обслуживания (SLA – Service-Level Agreement).Портфель приложений. Как будет меняться имеющийся набор прикладных систем?Интеграции бизнес-процессов. Как будут обеспечены интеграция и взаимодействие различных систем между собой? Это особенно важно в связи с ростом объемов электронного взаимодействия с поставщиками, партнерами и клиентами и распространением практики использования внешних ресурсов.Сорсинг. Обеспечение выполнения стратегии внутренними и внешними для департамента ИТ ресурсами.

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

Рис. 2.1.  Две области ИТ-стратегии и пять определяющих элементов

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

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

География бизнеса. Распределение производственных объектов, клиентов и партнеров. Это имеет непосредственное влияние на развертывание инфраструктуры и предоставление ИТ-сервисов. Вопросы, связанные с изменением портфеля приложений и их интеграцией, приобретают иной уровень сложности в географически распределенной среде.Организация принятия решений в компании (governance). Важно знать, каков механизм принятия решений – исключительно централизованный, или, наоборот, бизнес-подразделения самостоятельны в принятии решений, либо в компании существует какая-то промежуточная модель (некоторые из них описаны в лекции 2). При планировании стратегии ИТ необходимо адаптироваться к распределению центров власти и принятия решений.Горизонт планирования (будущее). Временная шкала, которую охватывает бизнес-стратегия и которую должна будет охватить ИТ-стратегия. Чем более широким является временной горизонт, тем в большей степени стратегические аспекты должны найти отражение в архитектуре ИТ. Если горизонт очень узок, то трудно вырабатывать долгосрочную стратегию ИТ.Существующие (унаследованные) бизнес-процессы и системы. Здесь определяется, насколько организация планирует жестко придерживаться принятых методов работы, или наоборот, насколько она готова изменять модели ведения бизнеса, а значит, соответствующие бизнес-процессы и те приложения, которые исторически их поддерживают.Виртуализация бизнеса. Интеграция с системами клиентов, партнеров, поставщиков и т.п. Этот аспект определяет, мыслит ли предприятие исключительно в терминах внутренних процессов организации бизнеса, или существует тенденция в существенной степени интегрироваться с клиентами и поставщиками. Желание рассматривать внешние организации как активных участников своих бизнес-процессов обычно значительно повышает требования в области интеграции. Это также влияет на принятие решений о том, какие прикладные системы останутся внутренними для организации, а какие будут переданы на аутсорсинг.Клиенты и заказчики (причем здесь могут рассматриваться потребности как внешних клиентов, так и внутренних пользователей информационных систем). Обслуживание клиентов может принимать различные формы, но степень взаимодействия с заказчиками во время процесса предоставления им услуг и соответствующие формы бизнес-процессов накладывают соответствующие требования на необходимую инфраструктуру ИТ.Финансирование ИТ. Это та область, которая явно показывает, насколько предприятие готово идти по пути изменений.

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

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

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

В результате мы получаем следующую "карту", имеющую форму матрицы 7 x 5, с помощью которой можно проанализировать влияние бизнес-стратегии на ИТ-стратегию. Она может показаться несколько сложной, но на самом деле это самый простой способ достаточно полного задания контекста для разработки реальной ИТ-стратегии.

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

Таблица 2.1. Матрица корреляции ИТ- и бизнес-контекстов для разработки ИТ-стратегииИТ-контекстИнфраструктураСервис (операции)ПриложенияИнтеграцияРесурсыБизнес-контекстГеографияПринятие решенийБудущееУнаследованные системыВиртуализацияКлиентыФинансирование

Расположение объектов, региональные особенности	Какой сервис нужен в каждой точке? Учет языков и культур	Каковы региональные особенности приложений?	Наличие интеграции приложений из разных узлов между собой	Кто принимает решения по интеграции?
Кто принимает решения по инфраструктурным вопросам?	Кто принимает решения по порядку обслуживания?	Стратегия изменения приложений	Кто принимает решения по интеграции?	Стратегия сорсинга
Соответствие архитектуры	Стратегия обслуживания	Какие приложения понадобятся для бизнеса в будущем?	Корпоративная архитектура масштаба предприятия	Какие компетенции понадобятся?
"Скорость" и стоимость изменений	Уровни обслуживания	"Скорость" и стоимость изменений	Как будет осуществляться интеграция и миграция?	Кто выполняет миграцию и обслуживание?
Координация инфраструктур с партнерами и поставщиками	Типы, уровни и стоимость сервиса	Приоритеты во внедрении	Интеграция между участниками партнерской сети	Кто и как будет обеспечивать взаимодействие с поставщиками?
Что требуется от ИТ?	SLA	Приоритезация требований	Кастомизация интерфейсов	Управление обслуживанием
Бюджеты операционных расходов на инфраструктуру	Расчеты по SLA	Как и из каких источников осуществляется финансирование изменений и новых приложений?	Выделение инвестиций в интеграционные проекты	Инвестиции в обучение и найм персонала

Организационные структуры, участники и роли в процессе создания стратегии ИТ

Организационные структуры, связанные с принятием решений в области стратегии ИТ, принадлежат к одной из двух категорий: формальные органы принятия решений и группы поддержки (например, группа разработки архитектуры).

Формальные органы принятия решений также бывают двух типов:

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

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

Таблица 2.2. Роли участников вне ИТ-службы

ДолжностьСовет директоровПрезидент/Генеральный директорФинансовый/Исполнительный директорРуководители бизнес-единиц (БЕ)АспектУчастие в разработке стратегииВклад в разработку стратегииВопросы компетенцииУчастие в реализации

Консультации по отрасли	Обеспечение интересов всех БЕ и учета всех функций	Обеспечение "присутствия" всех БЕ	Приоритеты БЕ, услуги по поддержке бизнес-направлений
Тенденции в отрасли, сценарии развития	Миссия и цели, выбор БЕ (рост, инвестиции)	Финансирование ИТ, финансовые и бизнес-риски	Новые рынки, клиенты, продукты, процессы
Соответствие уровня финансирования	Адекватность потребностям организации	Возможности финансовой поддержки, смягчение рисков	Адекватность потребностям бизнес-единиц
Периодический обзор на соответствие бизнес-целям	Контроль соответствия бизнес-стратегии, разрешение конфликтов между БЕ	Финансовые гарантии, контроль рисков	Отслеживание изменений в стратегии БЕ и их учет в общей ИТ-стратегии

Таблица 2.3. Роли участников из ИТ-службы

ДолжностьРуководитель ИТ-службы (CIO)Менеджеры по работе с БЕРуководители подразделений ИТ-службыИТ-АрхитекторыАспектУчастие в разработке стратегииВклад в разработку стратегииВопросы компетенцииУчастие в реализации

Формализация стратегии	Соответствие будущим потребностям и уровням услуг	Технические последствия реализации бизнес-стратегий	Варианты бизнес-сценариев и стратегических планов ИТ
Оценка имеющихся возможностей и потребностей	ИТ услуги, необходимые для БЕ	Тактика для поддержки бизнес-планов	Развивающиеся технологии, требуемая инфраструктура
Учет потребностей организации в целом и БЕ, гибкость	Необходимость и достаточность планов для реализации бизнес-целей	Перечень услуг, использование существующей инфраструктуры	Способы реализации бизнес-потребностей
Обзор планов и работ, реализация стратегии на тактическом уровне	Приоритеты, связь с БЕ	"Донесение" стратегии и тактики до персонала	Построение инфраструктуры

<
Отметим необходимость создания совместных команд с участием как специалистов ИТ, так и бизнес-подразделений, а также четкое определение и разделение ответственности. Существенным фактором успеха будет также являться организация эффективного взаимодействия между этими двумя частями совместной команды. Другой важный фактор связан с правильным составом команды и подбором участников. Здесь необходимо, с одной стороны, обеспечить представительство ключевых, с точки зрения последующей реализации проекта, сторон, а с другой – учесть сложившуюся в организации практику или даже "режим" принятия решений в области ИТ в соответствии с одной из возможных моделей (см. табл. 2.4) [7.17].

Таблица 2.4. Характерные профили управления информационными технологиями на предприятииРежимЛица, принимающие решения

Бизнес-монархия	Высшее руководство, возможно, с привлечением руководителя ИТ-службы
ИТ-монархия	Представители или группы ИТ-специалистов
Феодализм	Руководители подразделений или их "доверенные лица"
Федерация	Высшее руководство, с обязательным привлечением, по крайней мере, одного бизнес-подразделения
Двоевластие	ИТ-служба и, по крайней мере, одно бизнес-подразделение
Анархия	Все или большинство владельцев бизнес-процессов самостоятельно принимают решения в области ИТ

Процессы финансового управления

Существует три фундаментально отличных друг от друга типа процессов финансового управления:

составление бюджета и выделение фондов как часть ежегодного бюджетного цикла;ценообразование и модель компенсации затрат за полученные ИТ-услуги (Chargeback);проектное финансирование.

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

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

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

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

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

Ниже перечислены различные методы компенсации затрат по мере роста сложности их практического внедрения. Но большая сложность предлагает и большие возможности в плане реализации принципа сервисной организации в отношении департамента ИТ.

Традиционные методы компенсации затрат включают:

не связанные с ИТ метрики: например, пропорционально прибыли подразделения или пропорционально количеству сотрудников;связанные с ИТ параметры: например, в расчете на пользователя, в расчете на одну транзакцию;постоянный уровень расценок: например, базовая стоимость пакета услуг (Help desk и пр.) плюс дополнительная оплата услуг сверх стандартного пакета.

Менее традиционные методы компенсации затрат включают:

бизнес-ориентированные расценки. Это предполагает определение стоимости в терминах бизнес-активностей и в терминах связанных с ними ИТ-сервисов. Например, 5 центов за одно сообщение электронной почты или $10 за генерацию системой одного счета (или аналогичных бизнес- транзакций);цену, основанную на модели получения прибыли. Этот подход рассматривает департамент ИТ как еще одно бизнес-подразделение, которое должно работать, используя рыночные механизмы, и предлагать конкурентные ИТ-услуги внутри предприятия.

Вопросам проектного финансирования и управления портфелем ИТ-проектов посвящен следующий раздел.

Структуры управления и контроля и выбор финансовых критериев/инструментов

Структура управления, связанная с принятием решений в области ИТ-стратегии и методы финансовой оценки ее реализации связаны воедино так, как показано на рис. 2.2.

Рис. 2.2.  Модель финансового управления стратегией ИТ

Модель включает в себя три элемента:

организационные структуры принятия решений;финансовые инструменты принятия решений;процессы финансового управления.

Рассмотрим кратко все эти три элемента.

Связь портфеля ИТ-проектов и бизнес-стратегий

Основное внимание в управлении портфелем ИТ-проектов должно уделяться вопросам обеспечения соответствия портфеля ИТ-проектов бизнес-стратегиям предприятия. Это условно отражено на рис. 2.4.

Рис. 2.4.  Обеспечение соответствия портфеля ИТ-проектов бизнес-стратегии

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

Отметим также, что достижение желаемого соответствия между бизнес-стратегией и имеющимся на предприятии портфелем ИТ-активов является "стрельбой по движущейся цели". Меняется среда, и соответственно меняются конкурентные стратегии в ответ на изменения рынка. Создание портфеля ИТ-активов (приложений, инфраструктуры) – длительный процесс, который реализуется через выполнение проектов. Цель состоит в том, чтобы ИТ-проекты задавали правильное направление в развитии всего портфеля ИТ-активов предприятия, максимизируя ценность портфеля с точки зрения бизнеса предприятия.

Вернемся теперь к вопросу затрат на ИТ-проекты в контексте управления совокупным портфелем ИТ-активов, который включает в качестве составляющих элементов как прикладные системы, так и технологическую инфраструктуру, а именно, следующие четыре компоненты:

базовые транзакционные прикладные системы;информационные (дающие преимущества) прикладные системы;инновационные (стратегические) прикладные системы;инфраструктура.

Несколько вопросов представляют интерес, в частности:

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

Этим вопросам, в частности, посвящена книга Вейля [7.18]. Рисунок 2.5 показывает типичное, среднее для различных типов предприятий и индустрий распределение расходов [7.19].

Рис. 2.5.  Распределение инвестиций по элементам портфеля технологий предприятия

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

На базовые транзакционные прикладные системы в среднем тратится 13% бюджета. Характерной особенностью этих систем является то, что дополнительные затраты на новые транзакции ничтожно малы, если система уже инсталлирована и имеется необходимая инфраструктура. Системы, которые мы отнесли к разряду информационных (дающих преимущества), очень часто используют возможности транзакционных систем и обеспечивают коммуникационные возможности и возможности по совместной работе сотрудников внутри и вне компании. Затраты на них составляют в среднем 20% от бюджета на ИТ. Ну и, наконец, на инновационные (стратегические) системы расходуется в среднем 13% бюджета.

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

Так, утверждается, что есть положительная статистическая зависимость между увеличением инвестиций в базовые транзакционные системы и таким важным финансовым показателем, как возврат на основные фонды (ROA – Return on Assets). В то же время компании, которые больше инвестировали в базовые транзакционные системы, имели меньший рост оборота. То есть, это инвестиции с относительно невысоким риском, но с достаточно надежной, хотя и не всегда фантастически высокой, отдачей.

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

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

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

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

Рис. 2.6.  Синхронизация портфеля инвестиций в ИТ и бизнес-стратегии

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

Основные принципы управления портфелем ИТ-активов и проектов состоят в следующем [7.18]:

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


Рис. 2.7.  Портфель ИТ-проектов, профили рисков и возврата инвестиций

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

стратегические (инновационные) проекты – 25%;информационные (дающие преимущества) – 20%;базовые транзакционные системы – 11%;инфраструктурные проекты – 8%.



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

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

© 2003-2007 INTUIT.ru. Все права защищены.

Управление портфелем ИТ-проектов

Как уже отмечалось выше, составным элементом разработки ИТ-стратегии и одним из этапов процесса управления стратегией ИТ является формирование программы (плана реализации) ИТ-проектов. Перед принятием такой программы необходимо предварительно определить критерии, которые должны применяться при выборе и утверждении проектов, а также провести оценку соответствия ведущихся или уже запланированных проектов создаваемой стратегии. Соответствующий процесс в рамках реализации стратегии обычно обозначается как управление портфелем ИТ-проектов (Portfolio Management). Принципы управления портфелем ИТ-проектов являются одновременно и инструментом принятия решений об инвестировании в проекты наряду с финансовыми инструментами принятия решений, которые мы обсуждали в лекции 2. Заметим, что в больших организациях отдельные проекты обычно группируются в проектные программы. Программа – это набор проектов, которые в совокупности составляют некоторую крупную инициативу. Примером такой инициативы может быть создание корпоративного хранилища данных, что требует реализации нескольких параллельных и связанных между собой проектов, которые к тому же могут выполняться различными внутренними подразделениями организации или с привлечением внешних субподрядчиков.

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

Выбор приоритетов для инвестиций

Существенной частью общего портфеля ИТ-проектов и ресурсов является портфель прикладных систем. Интересно выделить аспект, связанный с принципами и объемами финансирования в организации трех типов различных прикладных ИТ-систем: базовые транзакционные (вспомогательные), дающие преимущества (информационные), инновационные (стратегические). Казалось бы, чем выше вклад в достижение бизнес-результатов и потенциальная отдача с точки зрения реализации бизнес-стратегий, тем выше должны быть объемы финансирования. Однако зависимости далеко не так очевидны. Заметим, какую часть занимают различные типы прикладных систем в общем портфеле. Большую его часть составляют базовые (обеспечивающие или вспомогательные) приложения, и именно здесь расходуется большая часть ИТ-бюджета.

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

проектное финансирование;от ранее производимых затрат (incremental budgeting);"бюджет с чистого листа" (zero-based).

Во-вторых, в структуре затрат на информационные технологии можно выделить обязательные затраты (non-discretionary) и затраты, связанные с развитием (discretionary). В свою очередь, затраты, связанные с развитием, можно разделить на две составляющие: инвестиции на развитие и венчурные инвестиции. Таким образом, мы имеем как бы три категории затрат в ИТ-бюджете:

обязательные затраты;необязательные затраты на развитие;венчурные инвестиции.

Следовательно, существуют три типа прикладных систем (базовые, дающие преимущества, инновационные), три подхода к бюджетированию и три категории затрат в ИТ-бюджете. Между ними есть четкие соответствия.

Мы говорили, что обязательные затраты составляют, как правило, 55-70%. Это затраты, которые просто необходимы для выполнения ежедневных, рутинных операций. Как правило, к этой части ИТ-затрат применяют подход, связанный с формированием бюджета "с чистого листа". В эту часть бюджета как раз и попадают те прикладные системы, которые мы назвали базовыми транзакционными (вспомогательными или обслуживающими). Вы просто оцениваете, сколько вы обязаны потратить на сопровождение и функционирование ключевых систем.

Из оставшейся суммы примерно 30-40% общего ИТ-бюджета выделяют на необязательные затраты, связанные с инвестициями в развитие. Прикладные системы, которые мы отнесли к категории дающих преимущества для бизнеса, обычно связаны с этой частью бюджета. Для данной категории затрат, как правило, используется подход к бюджетированию от ранее произведенных затрат, который предполагает, что отправной точкой для формирования бюджета являются затраты за предыдущий год. Условно говоря, это выглядит примерно так: "В текущем году мы потратим на усовершенствование нашей системы электронного документооборота $10000. В следующем году потребуется $12000, поскольку мы предполагаем чуть больший объем работ".

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

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

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

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

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

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

Квалификация и компетенция персонала

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

знание конкретных продуктов и технологий: например, серверы Windows, администрирование БД Oracle, XML, .NET, Java, CRM-системы, проектирование web-систем и т.д.;знания в области управления технологиями: например, моделирование бизнес-требований к системам, интеграция технологий, управление портфелем технологий, управление проектами, архитектура;навыки в области управления бизнесом: например, консультирование, умение обосновывать проекты (business-case development), финансовый анализ, оценка рисков, коммуникации, управление набором поставщиков, конкурентный анализ.

В 2001 году примерно 45% навыков собственных сотрудников службы ИТ были связаны со знаниями продуктов и технологий и еще примерно по 27-28% приходились поровну на знания в области управления технологиями и бизнес-знания [7.28]. Общая тенденция, однако, заключается в следующем: происходит рост в процентном отношении именно двух последних категорий знаний в том портфеле навыков, которым располагает сама служба ИТ. Очевидно, что это отражает общую практику, связанную с ростом объема "продуктовых и технических" ИТ-сервисов, передаваемых на аутсорсинг, а также большими объемами задач, решаемых в области управления технологиями, и задач на стыке бизнеса и информационных технологий, которыми занимаются департаменты ИТ.

Для исчерпывающей оценки набора знаний, которым располагает служба ИТ, можно воспользоваться моделью, которая выделяет 25 различных компетенций, связанных с информационными технологиями и разделенных на три категории [7.6]:

технические компетенции (6): понимание существующих систем и технологий; проектирование и разработка прикладных систем; применение процедур, средств и методов; интеграция систем; проектирование технической архитектуры; понимание новых технологий;бизнес-компетенции (9): понимание практики и подходов в области организации бизнеса; понимание организационных структур бизнеса, вопросов корпоративной политики и культуры; предпринимательское поведение; понимание и умение анализировать конкурентные ситуации; управление проектами; управление изменениями в области бизнеса, связанными с использованием прикладных ИТ-систем; планирование, приоритезация и администрирование работ; информирование, умение общаться и собирать информацию; фокус на клиентах;поведенческие компетенции(10): лидерские качества, умение вести за собой и внушать доверие; креативное и инновационное мышление; фокус на результатах; стратегическое мышление; умение давать наставления, делегировать полномочия и развивать персонал; построение отношений в коллективе и командная работа; влияние и убеждение; умение вести переговоры; разрешение конфликтов и проблем; умение адаптироваться.

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

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

Организационные структуры и функции подразделений департамента ИТ

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

Сразу сделаем замечание по поводу того, что названия структурных единиц (департаменты, управления, отделы), названия функций, их группировка и линии подчинения могут отличаться. Но в любом случае, перечисленные функции будут присутствовать практически всегда. Типичная структура департамента информационных технологий представлена на рисунке 3.3 [7.29].

Рис. 3.3.  Структура и функции департамента информационных технологий

Маленькие прямоугольники обозначают функции внутри более крупных прямоугольников, которые мы будем называть группами (в реальности, это могут быть управления, отделы, в зависимости от принятой практики наименования структурных единиц) внутри департамента информационных технологий. Обратим внимание на то, что большинство изменений традиционных структур департамента ИТ, которые происходили в последнее время, были связаны с квадратиками, расположенными в правой части этого рисунка: управление отношениями с клиентами, планирование и технологии, а также проекты. Это связано, прежде всего, с изменением роли, которую ИТ сегодня играют в деятельности предприятий, и с необходимостью обеспечения более тесной координации между бизнесом и ИТ. Квадратики в левой части (инфраструктура, разработка/внедрение) не претерпели кардинальных изменений за последние 10-20 лет. Функции финансов и администрирования также являются достаточно традиционными, хотя и в них происходили изменения, например, связанные с необходимостью применения новых финансовых инструментов оценки и инвестиций в ИТ, как обсуждалось выше.

Применение метода сбалансированных показателей (Balanced Score Card) для ИТ-области

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

В соответствии с известным определением Нортона, "стратегия есть изменение". Для оценки эффективности стратегии, то есть эффективности изменений, нужно обеспечить измеримость результатов такого процесса. Одним из наиболее распространенных инструментов для этого является методология Сбалансированных показателей эффективности (Balanced Score Card, BSC), предложенная Капланом и Нортоном еще в начале 1990-х годов для оценки бизнеса компании в целом [7.30]. Успех идей, заложенных в основу BSC, послужил толчком к созданию частных систем BSC для отдельных процессов, таких как управление клиентами или персоналом.

Традиционная методология BSC предполагает формирование так называемых стратегических карт (Strategic Maps), представляющих собой группировку целей и показателей по четырем категориям (перспективам):

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

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

Подобным же образом задают ключевые факторы функционирования информационных технологий на предприятии, причем в качестве объекта могут рассматриваться как собственно информационные системы, так и процессы управления ИТ. Сразу заметим, что многие процессы, особенно связанные с разработкой ИТ-стратегии и формированием Архитектуры предприятия, выходят за пределы собственно ИТ-cлужбы и требуют активного участия бизнес-подразделений и руководства организации. С другой стороны, в классической модели BSC информационные технологии являются как бы "слепым пятном" – то есть не присутствуют явно ни в одной из категорий.

Основными вопросами для построения BSC для ИТ на предприятии станут:

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

В качестве категорий (перспектив) системы BSC для ИТ могут быть выбраны, например, следующие:

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


Рис. 3.4.  Связь систем BSC для бизнес- и ИТ-областей

В каждой из этих категорий определяются свои ключевые показатели выполнения, формирующие "многомерный набор взаимосвязанных метрик (измерений), который используется для определения, оценки и изменения производительности". В качестве ключевых показателей ИТ службы можно использовать показатели, оцениваемые в подходах TVO (Total Value of Opportunities) и TCO (см. лекцию 5).

Заметим, что приведенный набор перспектив не является единственно возможным. Например, в [7.32] предлагается схожий, но немного отличающийся вариант:

миссия (основное предназначение и пути развития ИТ в компании);клиенты (цели поддержки основной деятельности компании);процессы (показатели эффективности процедур разработки и внедрения);технологии (оценка обоснованности и эффективности используемых технологий);организация (показатели эффективности внутренних процедур ИТ-департамента).

Роль ИТ-стратегии для развития ИТ-службы

Наличие ИТ-стратегии позволяет, наряду с обеспечением эффективности инвестиций в ИТ, решать и задачи укрепления имиджа ИТ-службы в компании (см. [7.33], [7.34]). Фактически речь идет о завоевании определенного уровня доверия (credibility) к ИТ-службе со стороны бизнес-подразделений. В частности, авторы этих публикаций предлагают выделять пять различных стадий такого доверия, которые приведены в табл. 3.1.

Таблица 3.1. Стадии доверия к ИТ-службе

НазваниеХарактеристика ИТ-службы со стороны бизнес-подразделенийКлючевые задачи ИТ-службы

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

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

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

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

Соответственно, в этих работах были выделены основные принципы реализации динамичности ИТ-службы, в том числе:

наличие определенной стратегии привлечения внешних исполнителей (стратегии сорсинга). Этим вопросам была посвящена лекция 3;создание и внедрение системы управления кадровыми ресурсами именно в ИТ-службах. Предполагается, что уже к 2005 году около 70% крупных и средних организаций будут иметь программу стратегического управления персоналом. Этот фактор получит особое значение для тех организаций, которые делают ставку на активное использование самых новых появляющихся технологий (так называемые предприятия типа A);развитие и расширение компетенций персонала ИТ-службы, в том числе направленных на более полное понимание бизнес-процессов организации, а также изменение стиля поведения за счет таких факторов, как ориентация на клиента и стратегическое мышление;развитие лидерских качеств;реализация процессного подхода, в том числе в области развития компетенций персонала (см. лекцию 3);адекватная организационная структура ИТ-службы, соответствующая бизнес-процессам компании (см. лекцию 3);обеспечение готовности персонала к изменениям и снижение сопротивления изменениям за счет предварительного информирования, разъяснения целей изменений, помощи в преобразованиях и соответствующего вознаграждения за результаты.

Стратегии сорсинга

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

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

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

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

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

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

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

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

Достаточно очевидным следствием существующих тенденций является тот факт, что для многих топ-менеджеров процесс управления внешними поставщиками услуг является более простым и понятным, чем использование "сложных и запутанных" ИТ-средств, связанных с необходимостью разработки ИТ-стратегии, утверждения ИТ-архитектур и т.п. Соответственно, для руководителя ИТ-службы вопрос привлечения внешних участников всегда будет "палкой о двух концах": либо это средство повышения эффективности ИТ, либо это угроза для самого существования отдельной ИТ-службы в составе организации. Очевидно, что для сохранения конкурентоспособности внутри организации сама ИТ-служба также должна применять передовые методы и средства для организации своей деятельности, связанные прежде всего с использованием сервисной модели. Специалисты Gartner предсказывают, что к 2006 году те службы, которые не перейдут на данную модель, с вероятностью 0,7 уступят по крайней мере 50% своих задач внешним поставщикам услуг.

Иерархия решаемых задач при формировании такой сервисной модели приведена на рисунке 3.1 [7.23].

Рис. 3.1.  Иерархия подхода к формированию стратегии сорсинга

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

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

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

Стратегия в области ИТ-персонала и сорсинга

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

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

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

Мы остановимся только на аспектах, связанных с сорсингом и организационными структурами, слегка затронув тему компетенции и квалификации персонала.

Архитектура операций (управления ИТ)

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

Архитектура информационных технологий предприятия состоит из комбинации различных сервисов и элементов: сервисов прикладных систем и элементов технологической инфраструктуры. Их набор и сочетание определяются потребностями бизнеса: стратегиями и бизнес-архитектурой. Задача архитектуры операций состоит в обеспечении необходимой инфраструктуры как для "новой" архитектуры (бизнес-процессов, приложений, данных), так и для "старых" систем. Архитектура операций должна решать эту сложную задачу, обеспечивая характеристики гибкости и высокой доступности технологий и систем.

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

Рис. 4.1.  Роль архитектуры операций и решаемые ею задачи

Понятие "Архитектуры операций" очень близко по смыслу к описанию реализации процессов управления и обслуживания ИТ в соответствии с принципами ITSM (IT Service Management – Управление ИТ-сервисами). В рамках этой архитектуры рассматриваются три элемента:

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

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

Внедрение принципов управления ИТ-сервисами ITSM, как правило, требует реинжиниринга ключевых процессов, связанных с эксплуатацией информационных технологий: управление изменениями, управление проблемами, управление ИТ-активами, создание общекорпоративной системы обслуживания пользователей (Service Desk). Этот процесс изменений должен носить постоянный характер, для того чтобы достичь должного уровня развития и улучшений. В данной области существуют некоторые де-факто стандарты, описывающие лучшие практики. Многие из них основаны на Information Technology Infrastructure Library (ITIL), которая является публично доступной библиотекой лучших практик управления ИТ-инфраструктурой и операциями как единым набором интегрированных процессов.


Рис. 4.2.  Архитектура ИТ-операций

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

COBIT как методика аудита процессов управления ИТ

СOBIT (Control Objectives for Information and related Technology) представляет собой систематизированный набор принципов и рекомендаций по проведению аудита процессов управления ИТ. Данная модель была впервые предложена профессиональной ассоциацией ISACA (The Information Systems Audit and Control Association) в 1996 году. Эта ассоциация позиционирует себя как международная организация, специализирующаяся на разработке общих стандартов в области аудита информационных систем. В 2000 году ее орган – Институт Управления ИТ, выпустил третье издание своих материалов. В случае с COBIT речь идет о позиционировании этой методологии как потенциального стандарта со стороны ее разработчиков.

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

Модель COBIT определяет 34 ключевых процесса управления ИТ в организации, которые сгруппированы в 4 основные области (домены). Список этих доменов включает:

Планирование и Организация (Planning and Organisation – PO).Приобретение и Реализация (Acquisition and Implementation – AI).Предоставление (реализация) и поддержка (Delivery and Support – DS).Мониторинг (Monitoring – M).

На следующем уровне в рамках этих 4-х доменов в стандарте определены 34 процесса, которые, в свою очередь, включают 318 различных задач. Список этих процессов верхнего уровня приведен в табл. 4.2.

Таблица 4.2. Cписок процессов верхнего уровня модели COBIT

Информационные критерииИТ-ресурсы

Домен

Процесс

Эффектив- ность (результат)

Эффектив- ность (усилия)

Конфиден- циальность

Целост- ность

Доступ- ность

Соответ- ствие

Надеж- ность

Лю- ди

Прило- жения

Техно- логии

Средства (facilities)

Дан- ные

Планирование и Организация

PO1

Разработка ИТ-стратегии

P

S

+

+

+

+

+

PO2

Разработка ИТ-архитектуры

P

S

S

S

+

+

PO3

Мониторинг технологического развития

P

S

+

+

PO4

Формирование ИТ-службы и определение взаимосвязей

P

S

+

PO5

Управление инвестициями в ИТ

P

P

S

+

+

+

+

PO6

Распространение корпоративной информации

P

S

+

PO7

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

P

P

+

PO8

Обеспечение соответствия внешним требованиям

P

P

S

+

+

+

PO9

Управление рисками

P

S

P

P

P

S

S

+

+

+

+

+

PO10

Управление проектами

P

P

+

+

+

+

PO11

Управление качеством

P

P

P

S

+

+

+

+

Приобретение и Реализация

AI1

Идентификация автоматизируемых решений

P

S

+

+

+

AI2

Приобретение и поддержка прикладного программного обеспечения

P

P

S

S

S

+

AI3

Приобретение и поддержка технологической инфраструктуры

P

P

S

+

AI4

Разработка и поддержка процедур

P

P

S

S

S

+

+

+

+

AI5

Установка и прием в эксплуатацию систем

P

S

S

+

+

+

+

+

AI6

Управление изменениями

P

P

P

P

S

+

+

+

+

+

Предоставле- ние и поддержка

DS1

Определение и управление уровнями обслуживания

P

P

S

S

S

S

S

+

+

+

+

+

DS2

Управление услугами третьих сторон

P

P

S

S

S

S

S

+

+

+

+

+

DS3

Управление производительностью и мощностью

P

P

S

+

+

+

DS4

Обеспечение непрерывности обслуживания

P

S

P

+

+

+

+

+

DS5

Обеспечение безопасности

P

P

S

S

S

+

+

+

+

+

DS6

Идентификация и управление стоимостью

P

P

+

+

+

+

+

DS7

Обучение пользователей

P

S

+

DS8

Помощь клиентам

P

P

+

+

DS9

Управление конфигурациями

P

S

S

+

+

+

DS10

Управление проблемами и инцидентами

P

P

S

+

+

+

+

+

DS11

Управление данными

P

P

+

DS12

Управление средствами

P

P

+

DS13

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

P

P

S

S

+

+

+

+

Мониторинг

M1

Мониторинг процессов

P

P

S

S

S

S

S

+

+

+

+

+

M2

Обеспечение адекватности внутреннего контроля

P

P

S

S

S

P

S

+

+

+

+

M3

Организация независимого контроля

P

P

S

S

S

P

S

+

+

+

+

+

M4

Обеспечение независимого аудита

P

P

S

S

S

P

P

+

+

+

+

+

<
В таблице буква "P" означает основной (primary) критерий, буква "S" – дополнительный (secondary), знак "+" отмечает применимость процесса для данного типа ресурсов.

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

Все процессы в COBIT определяются по одному и тому же шаблону: "процесс направлен на обеспечение первичных и вторичных Информационных критериев для бизнеса Предприятия, измеряемых с помощью набора Ключевых Целевых Показателей. Реализация процесса строится с учетом Критических факторов успеха, использует определенные Ресурсы, а ее характеристики измеряются с помощью набора метрик – Ключевых Показателей Производительности. Таким образом, оценка процесса может быть проведена с использованием количественных, измеримых параметров".

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



Для всех указанных процессов в модели, в соответствии с принципами CMM, определен набор уровней зрелости – от 0 до 5, характеризующих уровень реализации этого процесса в организации.

Для выбранных нами процессов PO1 и PO2, в СobIT используются следующие критерии отнесения процесса к определенному уровню зрелости.

Таблица 4.4. Критерии зрелости для процессов "Разработка стратегического плана развития ИТ" и "Разработка ИТ-архитектуры"P01 Разработка стратегического плана развития ИТP02 Разработка ИТ-архитектуры0. Несуществующий1. Начальный / Cпонтанный2. Повторяемый, но интуитивный3. Определенный4. Управляемый и измеримый5. Оптимизированный

В организации отсутствует понимание необходимости разработки ИТ-стратегии для решения задач бизнеса. Какая-либо активность отсутствует	В организации отсутствует понимание важности разработки ИТ-архитектуры вообще. Соответственно, у персонала отсутствует необходимый опыт и квалификация. Какая-либо ответственность не определена
Руководство признает необходимость разработки стратегии, однако процесс разработки не определен. Отдельные элементы планирования осуществляются по мере необходимости, поэтому результаты являются непоследовательными и спонтанными. Вопросы ИТ-стратегии обсуждаются иногда только в ИТ-службе, но не бизнес-руководством. Выбор решений осуществляется не на основе стратегии организации, а диктуется предложениями вендоров. Риски определяются неформально и привязываются к отдельным проектам	Руководство признает необходимость разработки архитектуры, однако не определило ни плана, ни процесса разработки. Отдельные мероприятия осуществляются не систематически и зависят от конкретного случая и инициативы исполнителя. Существует некоторое количество диаграмм и описаний процессов, обсуждение ведется спонтанно и непоследовательно. Предпочтение отдается не описанию требуемой для бизнеса информации, а описанию доступных де-факто данных, определенных существующими приложениями ИС
Разработка ИТ-стратегии понятна руководству, но не документирована. Она ведется ИТ-службой с привлечением бизнес-подразделений по необходимости. Изменения стратегии происходят только по запросу руководства, вне рамок формального процесса определения изменений бизнес-требований. Решения принимаются отдельно для каждого проекта. Преимущества стратегии, а также основные риски находят понимание на интуитивном уровне	В организации существует общая осведомленность по вопросам ИТ-архитектуры. Проводятся отдельные интуитивные мероприятия по разработке элементов архитектуры, которые могут быть частично скоординированы в рамках возникающего процесса и повторяться впоследствии. В то же время формальное обучение не проводится, а существенная часть опыта приобретается каждым участником самостоятельно. Решение вопросов ориентировано на краткосрочные тактические цели
Порядок, процедуры и ответственность за разработку ИТ-стратегии понятны, документированы и доступны всем. Процесс хорошо определен, и вероятность успешного планирования высока. Реализация этого процесса все еще вомногом зависит от индивидуальных исполнителей, регулярных проверок качества процесса нет. ИТ-стратегия включает последовательную оценку рисков, а также учитывает финансовые, технические и кадровые возможности при выборе новых продуктов и технологий	Необходимость разработки ИТ-архитектуры хорошо понятна и принята всей организацией, ответственность за отдельные работы четко определена. Процедуры, приемы и применяемые средства определены, документированы и внедрены. На основе стратегических бизнес-целей определены наиболее общие архитектурные принципы и стандарты, хотя соответствие им не всегда последовательно соблюдается и проверяется. Реализована на практике функция администрирования, ответственная за распространение стандартов, и отчетность по их использованию
Стратегическое планирование ИТ является стандартным процессом, отклонения от которого будут заметны для руководства. Для процесса определена ответственность на высшем уровне, а также обеспечивается его мониторинг и оценка эффективности. Ведется как краткосрочное, так и долгосрочное планирование. ИТ-стратегия совместно с бизнес-стратегией направлены на получение преимуществ для бизнеса за счет внедрения новых приложений и проведения реинжиниринга бизнес-процессов. Существует хорошо определенный процесс оптимизации использования внутренних и внешних ресурсов. Проводится формализованное количественное сравнение показателей ИТ-системы с данными конкурентов и отраслевыми нормами	Разработка и внедрение ИТ-архитектуры полностью поддержана формальными методиками и процедурами. Обеспечивается возможность количественного измерения производительности процесса разработки и успешности применения его результатов на практике. Обучение определено, документировано и последовательно применяется в рамках всей организации. Процесс разработки поддержан соответствующими автоматизированными средствами, хотя они могут быть и не полностью интегрированы. Определены и применяются внутренние "лучшие практики". Базовые метрики процесса определены и объединены в целостную измерительную систему. Сам процесс учитывает изменения требований бизнеса и ориентирован на достижение стратегических целей. Реализован автоматизированный репозитарий ресурсов описания архитектуры, позволяющий использовать эту информацию в системах принятия решений и информирования руководства
Стратегическое планирование обеспечивает ощутимые бизнес-преимущества за счет инвестиций в информационные технологии. Планирование ИТ неразрывно связано с планированием бизнеса. Существует долгосрочная реалистичная ИТ-стратегия, которая постоянно обновляется с учетом технологических инноваций и изменений требований бизнеса. Краткосрочные планы содержат определенные этапы, выполнение которых постоянно отслеживается, а параметры корректируются в зависимости от изменений. Формализованное количественное сравнение ИТ-показателей с лучшими отраслевыми практиками интегрировано в процесс разработки стратегии. Инновации в ИТ-технологиях отслеживаются и используются для развития бизнеса	Архитектура ИТ-системы последовательно внедряется на всех уровнях, и ее важность для бизнеса постоянно подчеркивается. Персонал ИТ-службы обладает необходимым опытом и квалификацией, позволяющей строить и модифицировать архитектурные решения в соответствии с изменяющимися требованиями бизнеса. Организация широко применяет доступные лучшие практики, в частности, использование хранилищ данных и средства анализа данных. Ведется постоянное развитие и совершенствование ИТ-архитектуры

Методики Microsoft для управления

ИТ-системами и операциями

Помимо методики MSF, ориентированной на обеспечение процесса разработки прикладных систем, Microsoft разработала методику, содержащую специализированные компоненты для управления ИТ – MOF (Microsoft Operations Framework). Эта методика представляет интерес для специалистов, поскольку она, с одной стороны, учитывает весь опыт ITIL, а с другой стороны – в большей степени ориентирована на продукты и технологии Microsoft, которые де-факто лежат в основе ИТ-инфраструктуры большого количества организаций. Кроме того, MOF в определенных областях расширяет область применимости ITIL, например, в управлении распределенной ИТ-инфраструктурой или в таких новых для индустрии направлениях, как хостинг приложений, web-транзакции и системы электронной коммерции.

MOF предоставляет организациям, создающим критически важные (mission-critical) ИТ-решения на базе продуктов и технологий Microsoft, технические руководства по достижению надежности, доступности, удобства сопровождения и управляемости систем. MOF затрагивает вопросы, связанные с организацией персонала, процессов, технологиями и менеджментом в условиях сложных, распределенных и разнородных ИТ-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL).

MOF состоит из следующих трех моделей:

модель процессов;модель команд;модель рисков.

Подробная информация по MOF доступна в Интернет по адресу http://www.microsoft.com/mof/.

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

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

За решение первой задачи (анализ потребностей и создание удовлетворяющих их решений) отвечает MSF, в то время как MOF адресуется второй задаче (эксплуатация решений в повседневной деятельности предприятия).

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

Создание и эксплуатация новых решений, согласно MOF и MSF, состоят из четырех базовых этапов:

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

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

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

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

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

фаза выработки концепции (Envisioning);фаза планирования (Planning);фаза разработки (Developing);фаза стабилизации (Stabilizing);фаза внедрения (Deploying). Фазы могут содержать также промежуточные вехи.




Рис. 4.3.  Модель процессов MSF

Модель процессов MOF описывает процессы, связанные с эксплуатацией ИТ-систем и включает четыре квадранта и соответствующие каждому квадранту четыре контрольных процесса (review):

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


Рис. 4.4.  Модель процессов MOF

Методика Microsoft Solutions for Management (MSM) в какой-то степени дополняет MOF. MSM ставит во главу угла не технические детали реализации информационной системы, а составляющие ее логическую схему процессы, что позволяет добиться универсальности рецептов, содержащихся в ее решениях. Однако даже при современном уровне техники процессы автоматизации остаются лишь инструментами в руках использующих их людей. Поэтому MSM рассматривает ИТ-кадры предприятия как еще один важный фактор в системе управления. Третья составляющая цепочки управления – технологии, задействованные в ИТ-инфраструктуре компании. Для того чтобы объединить эти три фактора в эффективную структуру управления, MSM предлагает прибегать к помощи комплекса специально разработанного программного обеспечения.

MSM включает в себя теоретическую базу, а также лучшие практические примеры внедрения и автоматизации. MSM опирается на модель Microsoft Operations Framework (MOF) – набор шаблонов и методических инструкций по планированию, внедрению и дальнейшей поддержке информационных процессов.

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

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

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

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

Сценарии, в отличие от моделей, представляют собой примеры решений в области управления ИТ-инфраструктурой, связанные с конкретными программными продуктами Microsoft. MSM включает в себя, в частности, такие сценарии, как: распространение обновлений (позволяет быстро, эффективно и управляемо внедрять выпущенные Microsoft обновления программных продуктов, используя Systems Management Server); мониторинг и управление службами (автоматизирует мониторинг доступности каталога Active Directory, Exchange и SQL Server на Windows Server); оценка функционирования (дает возможность пользователям идентифицировать точки главных проблем и разработать план, адресуемый им); установка Microsoft Office (позволяет быстро, эффективно и управляемо внедрять Microsoft Office).

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

Оценки зрелости процессов

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

Уровни зрелости обычно определяются в соответствии с заданной моделью, которая описывает их иерархию и правила измерения (оценки), по которым можно, на основе изучения соответствия определенных характеристик процесса, отнести его к определенному уровню. Общепризнанное распространение получила модель уровня зрелости (Capability Maturity Model – CMM), предложенная Институтом системного инжиниринга (SEI) при Университете Карнеги-Меллона, прежде всего для оценки процесса разработки программного обеспечения. Все такие модели базируются на работах Кросби.

Предпосылками для создания этой модели явились прежде всего глобальные проблемы качества информационных систем, связанные с наличием большого числа дефектов программного кода, которые приводили к возникновению ошибок, сбоев и непредсказуемости работы приложений. Понятно, что наиболее критичным образом эти проблемы проявлялись в специализированных областях, прежде всего в военных системах и в научных расчетах, большая часть которых, опять же, была прямо или косвенно связана с решением военных задач. Однако бурное развитие информационных технологий с середины 50-х годов прошлого столетия привело к тому, что сейчас практически все аспекты жизни современной цивилизации немыслимы без применения компьютеров. Очередной скачок в понимании актуальности качества работы информационных систем был вызван появлением персональных компьютеров в начале 1980-х и резким увеличением числа разработчиков и пользователей. Другой аспект проблемы оказался связан с неудовлетворительной организацией управления проектами разработки программного обеспечения и с вытекающими последствиями в виде срыва сроков, превышения бюджета или даже отмены проектов. Хорошее описание возникающих проблем приведено в известных книгах Брукса [8.3] и Йордана [8.4]. Так что начало работы института SEI в данном направлении в 1986 году оказалось очень своевременным, а возможно даже слегка запоздалым.

Результатом работы SEI стало появление модели CMM для разработки программного обеспечения (версия 0.6 была опубликована в 1990 г., версия 1.0 – в 1991 г., версия 2 – в 1997 году). Для отнесения компании-разработчика программных систем к определенному уровню была предложена специальная система сертификации. По многим независимым оценкам, внедрение (подтвержденное соответствующей сертификацией) в организации практик, соответствующих высшим уровням модели, позволяет значительно повысить шансы на успешное завершение проекта – с типовых 30% до 85%.

Пожалуй, основной идеей CMM явилось понятие системы определенных Уровней Зрелости (Maturity Levels) процесса, которые охватывают набор так называемых ключевых областей (Key Process). В рамках CMM были определены 5 таких уровней, которые позволяют свести все многообразие вариантов организации процесса разработки к небольшому диапазону номеров уровней. Это позволяет решить первую задачу: обеспечить измеримость процесса в целом. Контролируемость и управляемость процесса определяются возможностями последовательного перехода с уровня на уровень при выполнении определенных условий.

Далее развитие стандарта в соответствии с пожеланиями основного заказчика проекта, Министерства Обороны США, продолжилось в рамках новой модели CMMI – CMM Integration. Обе эти модели очень схожи между собой по целям и подходам – обеспечение измеримости, контролируемости и управляемости процессов организации, но несколько отличаются в терминологии и структуре модели. При разработке CMMI использовались модели CMM для разработки не только программного обеспечения, но и других областей, так что CMMI служит, в определенном смысле, универсальным стандартом, который может применяться для управления качеством. Версия CMMI 1.1 была опубликована в 2002 году. CMMI, собственно говоря, является не описанием процессов, а скорее руководством по их разработке.

В рамках CMMI вводится дополнительная классификация более высокого уровня – разделение на непрерывную и поэтапную реализацию. Для непрерывной реализации вместо 5 уровней определяется 6, которые слегка отличаются по названию и содержанию от соответствующих уровней CMM – здесь вместо понятия уровня зрелости используется понятие уровня устойчивости. Вместо ключевых областей, определенных в CMM, в CMMI используется понятие областей процесса (process areas), которые направлены на достижение целей двух типов – общих (generic) и специфичных для данной системы.

В таблице 4.1 приведены сравнительные характеристики уровней зрелости для разработки программного обеспечения (в соответствии с моделью CMM) и поэтапной реализации в рамках CMMI.

Таблица 4.1. Уровни зрелости процесса разработки программного обеспечения в соотвествии с моделями CMM и CMMI

Название в CMMНазвание в CMMIХарактеристики

1	Начальный	Начальный (этот уровень присваивается по умолчанию)	Процесс разработки программного обеспечения спонтанен и во многом хаотичен. Успех зависит от индивидуальных способностей участников и не может быть повторен без их привлечения. Даже если созданные продукты работоспособны, проекты чаще всего существенно превышают заданные сроки и бюджеты
2	Повторяемый	Управляемый	Организация применяет методы лучшей практики для управления функциональностью, сроками и бюджетом проекта. Возможно повторное использование успешных решений
3	Определенный	Определенный	Процесс разработки документирован, стандартизован и утвержден. Процессы последовательно применяются в рамках всей организации
4	Управляемый	Управляемый количественно	Для процессов определены специальные метрики, которые позволяют количественно определить уровни организации и определить степень готовности продукта
5	Оптимизированный	Оптимизированный	Существует возможность предсказания результатов процесса и работоспособности продукта Производится постоянное усовершенствование процессов на основе анализа измеряемых результатов. Процессы направленным образом изменяются для достижения новых целей

<
Достаточно содержательное введение в проблематику CMMI можно найти, например, в публикации [8.5].

Сама по себе CMMI не рассматривает многие домены архитектуры (данные, интеграция, безопасность, архитектуру ИТ-операций и т.п.). Кроме того, она приводит основные задачи (например, определить метрики для процессов), но не описывает, как именно нужно это делать, т.е. не содержит рекомендаций. Тем не менее, предложенный в рамках моделей CMM/CMMI подход оказался настолько удачным, что аналогичные шкалы уровней зрелости стали широко применяться и в смежных областях, которые не ограничиваются только разработкой программного обеспечения, – в том числе, управления поставками, кадровыми ресурсами или бизнес-процессами предприятия в целом (cм., например, http://www.bptrends.com).

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

Организация управления ИТ-системами и ITIL

Современным подходом (или даже философией) в правильной организации процессов управления ИТ является ITSM – IT Service Management. Его суть состоит в переходе от решения отдельных технических задач по поддержке компонентов информационных систем к оказанию комплексных бизнес-ориентированных услуг гарантированного качества. При этом ИТ служба рассматривается как сервисная организация – поставщик информационных услуг.

Одним из важных концептуальных источников для реализации ITSM является ITIL – IT Infrastructure Library, которая стала, пожалуй, первым достаточно полным описанием лучшей практики организации процессов управления информационными технологиями в организации. Данная библиотека была разработана в конце 1980-х годов в Великобритании Правительственным агентством по коммерции и достаточно долгое время была распространена только в Европе. ITIL представляет собой обобщение лучшего международного опыта в области организации и управления информационными технологиями.

Главный акцент ITIL делается прежде всего на описании сервисов и поддержки. Основные процессы, рассматриваемые в ITIL:

управление инцидентами (Incident management);управление проблемами (Problem management);управление конфигурациями (Configuration management);управление изменениями (Change management);управление версиями (Release management);управление планированием (Capacity management);управление доступностью (Availability management);управление уровнями обслуживания (Service-level management).

Фундаментальным принципом является предложенный в ITIL принцип сервисного подхода к реализации функций управления информационными системами в организации. В соответствии с этим принципом ИТ-служба, с одной стороны, оказывает определенные услуги производственным (бизнес)-подразделениям организации в рамках системы заключаемых так называемых Соглашений об уровне обслуживания (Service Level Agreement – SLA), а c другой – она выступает от имени предприятия получателем этих услуг со стороны внешних организаций.

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

Более подробная информация об ITIL доступна на сайте http://www.ogc.gov.uk, а ограничения модели обсуждаются, в частности, в публикациях Gartner [8.1], [8.2]. Идеи, заложенные в ITIL, были конкретизированы ведущими производителями решений и систем в своих фирменных методиках, поддержанных соответствующими специализированными программными средствами. Поэтому за последние несколько лет ITIL значительно расширила свое распространение во всем мире, особенно после того как многие ведущие производители программных и аппаратных средств использовали ее для разработки и популяризации своих эталонных моделей. Такие модели, с одной стороны, включают необходимые рекомендации по совершенствованию процессов управления ИТ, с другой – содержат полезные расширения. К числу этих моделей относятся, прежде всего, ITSM RM (Information Technology Service Management Reference Model) от HP и модель MOF (Microsoft Operations Framework) от Microsoft, которую мы рассмотрим более подробно в следующем разделе.

---

---