ИТ - стратегия

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

...Перед главнокомандующим, особенно в трудную минуту, бывает не один проект, а всегда десятки одновременно. И каждый из этих проектов, основанных на стратегии и тактике, противоречит один другому. Дело главнокомандующего, казалось бы, состоит только в том, чтобы выбрать один из этих проектов. Но и этого он не может сделать. События и время не ждут.
Л. Толстой. "Война и мир"
Осмелимся сделать следующее заключение об отечественном опыте и практике использования слов "стратегия" и "архитектура". Складывается впечатление, что общей является следующая ситуация: в России и бизнес-руководители, и руководители в области ИТ чаще мыслят в терминах "стратегий", т.е. "бизнес-стратегий" и "ИТ-стратегий" соответственно. Особенно это характерно для области государственной информатизации. За последние десять с лишним лет под ее эгидой было опубликовано несколько различных "стратегий" (под названием "Концепция" или "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, которую мы рассмотрим более подробно в следующем разделе.

ИТ - стратегия

Оценка перспективности инвестиций в ИТ по методике TVO

Важным вопросом является формальное обоснование процесса разработки архитектуры, в понятных финансистам терминах, и сделать это нужно еще до инициирования процесса. Самым простым и традиционным показателем может, конечно, служить величина возврата от инвестиций (Return-on-investment, ROI). Однако далеко не все инвестиции в архитектуру предприятия могут быть достаточно просто сопряжены с конкретным доходом. С другой стороны, использование ROI "предполагает" получение доходов, связанных с внедрением данных новшеств в достаточно короткий срок, который ограничен горизонтом проекта. Более того, в ROI не учитываются неопределенности и риски. Соответственно, многие "полезные, с точки зрения архитектора", ИТ-проекты могут не получить необходимого финансирования.
Среди отечественных работ в данной области можно отметить публикацию [8.13], в которой проводится сравнение различных вариантов обоснования эффективности инвестиций в ИТ.
Поэтому, в соответствии с точкой зрения аналитиков Gartner, приведенной в работе [8.14], более правильным является учет стратегического влияния результатов таких проектов на дальнейшее развитие систем и бизнеса в целом. Соответствующими показателями будут в данном случае являться рентабельность активов (ROA) и TVO (Total Value of Opportunity) – Ценность возможностей для бизнеса. Так как многие инвестиции в ИТ-архитектуру являются долгосрочными, то использование такого показателя как ROA, позволяет более корректно учитывать увеличение капитализации компании. Показатель TVO, хотя он не является чисто финансовым, позволяет связать реализацию данных проектов с расширениями возможностей бизнеса.
Эффективность инвестиций может быть проиллюстрирована диаграммой, приведенной на рисунке 5.2. Обычно инвестиции в ИТ связаны с низшими тремя уровнями в том смысле, что инвестиции могут быть обоснованы с использованием соответствующих метрик и показателей, таких как, например, среднее время выполнения процесса обработки заказа. Однако более существенный эффект для бизнеса будет связан с изменениями на верхних уровнях, которые станут возможными на основе реализованных проектов.

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

Шаг 1: Четкая формулировка названия и целей проекта и идентификация типа инвестиций.

Шаг 2: Оценка преимуществ для бизнеса, которые определяются в соответствии с некоторой моделью показателей, называемой Моделью эффективности бизнеса (Business Performance Framework) (см. ниже).

Шаг 3: Идентификация функциональных возможностей (capabilities), реализуемых внедряемыми новыми технологиями.

Шаг 4: Оценка влияния возможностей технологий на метрики, определенные в Модели эффективности бизнеса.

Шаг 5: Оценка финансовой составляющей проекта, определяемой с учетом совокупной стоимости владения (TCO), включая скрытые и косвенные затраты.

Шаг 6: Оценка возможностей предприятия с точки зрения конвертирования технологических преимуществ от реализации проекта в ощутимые выгоды для бизнеса.

Шаг 7: Оценка косвенных выгод и неопределенностей, связанных с влиянием реализуемых решений на другие проекты в будущем.

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

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

Инвестиции, связанные с инфраструктурой: трансформация инфраструктуры и обновление инфраструктуры.

Инвестиции, связанные с прикладными решениями: улучшения в процессах и эксперименты.

На втором шаге выбираются метрики для оценки отдачи от ИТ-проекта с точки зрения получения бизнес-преимуществ. Преимущества для бизнеса могут быть перечислены в рамках некоторой модели взаимосвязанных сгруппированных показателей (по аналогии с системой показателей Balanced Sсore Card – BSC). Компанией Gartner была разработана соответствующая Модель эффективности бизнеса (Business Performance Framework) [8.15], которая включает наборы показателей (метрики), покрывающие основные области деятельности организации, такие как адекватность требованиям рынка, эффективность процесса продаж и т.д. Очевидно, что не только технологии вносят вклад в достижение тех или иных показателей ведения бизнеса, однако, предлагаемые метрики позволяют построить причинно-следственные связи.


Примечания к таблице:

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

** Стоимость конверсии представляет собой отношение затрат на приобретение исходных материалов к стоимости произведенных товаров.

*** Величина Сигма связана с количеством дефектов произведенных товаров.

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

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

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

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

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

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

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

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

Рис. 5.5.  Условное позиционирование дисциплин управления и аудита ИТ
Таким образом, можно выделить две основные группы подходов, первая из которых существенно ориентирована на специфику ИТ, а вторая изначально предназначалась для совершенствования бизнеса. Соответственно, для первой группы необходимой задачей является обоснование получаемого эффекта на понятном для руководства организации и бизнес-пользователей языке. Для второй группы требуется, как правило, определенная доработка с учетом специфики информационных технологий. Применимость отдельных подходов в каждом конкретном случае может зависеть и от субъективных факторов, в том числе от должности руководителя, ответственного за преобразования. Так, вполне вероятно, что финансовому директору будут более понятны идеи TCO, а исполнительный директор предпочтет основанный на системе показателей эффективности подход Balanced Scorecard.
В таблице 5.3 приведены основные связи между указанными дисциплинами и предметом нашего рассмотрения.

Таблица 5.3. Сравнительное описание различных дисциплин управления и аудита ИТИТ-стратегияИТ-архитектура

TCO	Стратегия может предусматривать оптимизацию TCO в качестве одной из целей развития ИС	Реализация корпоративной архитектуры объективно способствует снижению TCO
ITIL (ITSM, MOF)	Внедрение процессов, основанных на ITIL, часто предусматривается в качестве одной из стратегических целей организации	ITIL определяет лучшие практики реализации процессов управления ИТ, получающих преимущества при наличии корпоративной архитектуры
CMM (CMMI)	CMMI может использоваться для оценки зрелости процесса стратегического планирования, СMM-SW – для оценки зрелости процесса разработки программного обеспечения	CMM-подобные шкалы применяются для оценки зрелости корпоративной архитектуры в целом и отдельных компонент и/или процессов
COBIT	В СOBIT проводится оценка состояния процесса стратегического планирования	В СOBIT проводится оценка состояния процесса разработки и поддержки архитектуры
TVO	TVO может использоваться для определения взаимосвязей между ИТ- стратегией и бизнес-стратегией организации	Показатель TVO позволяет связать инвестиции в корпоративную архитектуру с расширениями возможностей бизнеса
BSC (Balanced Score Card)	Создание BSC для ИТ-службы и установление связей с общей BSC может предусматриваться в качестве одной из стратегических целей организации	Оптимизация архитектуры отражается в значениях показателей, входящих в BSC

Можно заметить, что рассмотренные методики и подходы частично "пересекаются" друг с другом, так что в отдельных аспектах анализа процесса управления ИТ становятся возможными неоднозначности в описаниях и рекомендациях. В работе [8.20] описана достаточно интересная попытка создания так называемой "объединенной рамочной модели" процессов управления (UPF – unified process framework), сфокусированной именно на обеспечении соответствия ИТ и бизнеса. Автор надеется, что такая методика, подкрепленная соответствующими инструментами, появится где-то к 2008 году.

Можно заметить, что рассмотренные методики и подходы частично "пересекаются" друг с другом, так что в отдельных аспектах анализа процесса управления ИТ становятся возможными неоднозначности в описаниях и рекомендациях. В работе [8.20] описана достаточно интересная попытка создания так называемой "объединенной рамочной модели" процессов управления (UPF – unified process framework), сфокусированной именно на обеспечении соответствия ИТ и бизнеса. Автор надеется, что такая методика, подкрепленная соответствующими инструментами, появится где-то к 2008 году.

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

Учет стоимости владения ИТ (TCO)

Развитие информационных технологий и рост их значения для обеспечения потребностей бизнеса объективно приводят к увеличению расходов на ИТ. В настоящее время уровень затрат на информационные технологии предприятия приближается, а иногда и превышает уровень инвестиций в другие производственные процессы, вместе взятые, поэтому обеспечение оптимальной стоимости ведения бизнеса на основе информационных систем становится одной из основных задач поддержания требуемого уровня конкурентоспособности организации на рынке.
Идентификация всех затрат, связанных с информационными технологиями, может потребовать кропотливой работы, но результаты бывают просто поразительными. Например, зачастую организации учитывают только прямые затраты на приобретение программного обеспечения, в то время как косвенные затраты, связанные с сопровождением и поддержкой (обновление и пр.), как правило, не учитываются. При этом есть данные, что на каждые сто долларов инвестиций в программное обеспечение приходится еще 20 долларов ежегодных затрат на сопровождение и 40 долларов на поддержку.
В сложившихся условиях проблема оценки эффективности вложений в ИТ становится чрезвычайно актуальной. Какой должна стать корпоративная информационная система (т.е. какова целевая архитектура)? Какие инвестиции требуются для ее создания и сопровождения? Как добиться (т.е. какая должна быть стратегия) разумного соотношения между размерами этих инвестиций и той выгодой, которая может быть получена от использования информационных систем? Эти и многие другие похожие вопросы (по крайней мере, время от времени) беспокоят руководство всех компаний.
Зарубежный опыт решения задач оценки эффективности инвестиций в ИТ показывает, что одним из наиболее широко распространенных методов является применение концепции оценки Совокупной Стоимости Владения ИТ (Total Cost of Ownership – ТСО).
Концепция TCO была развита компанией Gartner в середине1990-х годов путем интеграции существовавших моделей Gartner и разработок приобретенной компании Interpose. Под показателем ТСО понимается сумма прямых и косвенных затрат организации на эксплуатацию своих информационных систем.
Здесь стоит особенно подчеркнуть наличие фактора косвенных затрат.
В отличие от ИТ-бюджетов, которые включают только прямые затраты, в показатель TCO включается и оценка затрат косвенных, связанных с недостатками в работе информационных систем, в том числе:

потери времени сотрудников на самообучение;

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

потери времени сотрудников на помощь коллегам в решении вопросов поддержки информационных систем;

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

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

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

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

формирование модели совокупных затрат на ИТ предприятия и определение эффективности существующих затрат на эксплуатацию информационных систем;

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

оценка затрат и экономического эффекта мероприятий по достижении целей развития информационных систем.

Для количественного анализа используются специальные программные средства типа TCO Manager. Сам по себе расчет не сложен и фактически реализуется на уровне электронных таблиц. Большую ценность имеет возможность сравнения результатов TCO для конкретной организации с представительной базой, созданной по результатам анализа показателей в других компаниях аналогичного профиля. Gartner ведет обширную базу данных клиентов по измерению показателей TCO для различных индустрий и характера вычислительной среды. Сравнение может производиться как со средними показателями по выбранной группе аналогичных компаний, так и с "лучшими в группе". Средние и лучшие показатели рассчитываются и отслеживаются экспертами Gartner по многим предприятиям различных отраслей, так что база этих показателей периодически обновляется. Возможен также анализ типа "что – если", который позволяет смоделировать возможное влияние планируемых решений в области архитектуры – например, по консолидации серверов, на показатель TCO.

Следует отметить, что имеет смысл сравнивать показатели TCO для сопоставимых между собой областей применения ИТ в организации – в рамках некоторой единой модели. Типичным примером является так называемая модель TCO для распределенных вычислений (TCO for distributed computing). Она описывает применение ИТ в гражданской организации – прежде всего, для задач управления. Предполагается, что существенная часть затрат связана с наличием достаточно большого числа пользователей – сотрудников организации, использующих персональные компьютеры (или терминалы), стандартные офисные приложения (текстовый редактор, электронная таблица, электронная почта и т.д.) и, возможно, некоторые специализированные приложения (ERP, CRM,ѕ) для ввода, обработки, анализа, хранения и распространения информации. Надо заметить, что эта категория затрат составляет, как правило, существенную часть от общих затрат на информационные технологии типичной организации.

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

Модель TCO для распределенных вычислений выделяет 5 категорий затрат, составляющих Совокупную Стоимость Владения, три из которых относятся к прямым затратам, а две – к косвенным [8.8].

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


Косвенные затраты, связанные с распределенными вычислениями, включают, как отмечено выше, следующие категории:

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

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

Типичное распределение затрат TCO по категориям для распределенных вычислений (на настольных ПК используется операционная система Windows XP и офисные приложения Microsoft) показано на рис. 5.1. При этом величина TCO составляет около $4750 на пользователя в год.


Рис. 5.1.  Типичное распределение TCO по категориям затрат

Важно обратить внимание, что TCO для распределенных вычислений существенным образом зависит от того, насколько эффективно ИТ-служба управляет инфраструктурой. Для средней организации, использующей Windows 2000/XP, этот показатель может быть на 11% меньше, чем в организации, в которой не реализованы процессы управления. А в организации, которая эффективно управляет ИТ-инфраструктурой, TCO может быть меньше на 37% [8.9]. От эффективности управления существенно (буквально, в несколько раз) зависит получение экономии прямых и косвенных затрат, связанных с переходом на более новые версии программного обеспечения.

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

В состав типового проекта по оценке TCO входят такие работы, как:

сбор и консолидация данных по затратам на ИТ;

анализ затрат на ИТ;

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

расчет затрат и выгод от внедрения технических средств;

анализ возврата инвестиций в ИТ;

сравнение показателей ИТ организации с показателями аналогичных компаний;

оценка работы персонала ИТ-службы;

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

разработка рекомендаций по оптимизации TCO.

Более подробную информацию по TCO можно найти в Интернет, в т.ч. на сайте http://www3.gartner.com/4_decision_tools/measurement/decision_tools/tco/tco.html, а также в книге К. Скрипкина [8.10], посвященной анализу экономической эффективности информационных систем. Достаточно интересные примеры из практики расчетов по модели TCO, детальное обсуждение методических вопросов и примеры лучших практик по управлению TCO приведены в книге В. Баронова с соавторами [8.11]. Здесь, в частности, отмечается важность использования поправочных коэффициентов, отражающих российские реалии.

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

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

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

Мы уже отмечали, что капитальные затраты на информационные технологии могут составлять значительную часть общих капитальных затрат организации, а их абсолютные величины, даже в средних по масштабам бизнеса организациях, могут исчисляться миллионами долларов в год. Это определяет актуальность четкой организации как процессов управления существующими ИТ-активами, так и процессов управления закупками. Нужно отметить, что стандартные подходы и средства автоматизации учета материальных активов не решают всех необходимых задач из-за недостаточного учета специфики предмета, поэтому в данной области часто используются специализированные средства.
Очевидно, что управление ИТ-активами (мы рассматриваем здесь только аспекты управления жизненным циклом ИТ-активов, не включая мониторинг и управление работой систем и элементов в реальном времени) и инвестициями достаточно тесно связано как с существующей и целевой архитектурой информационных систем, так и с совокупной стоимостью владения ими.
Закупки оборудования и услуг, реализация проектов являются частью общего процесса управления инвестициями в информационные технологии, который предполагает соответствующее планирование, оперативное исполнение и последующую оценку эффективности. Для оценки качества этого процесса также нашла применение CMM-подобная модель зрелости. В частности, такая модель была рекомендована Финансово-контрольным управлением США (GAO) для использования во всех правительственных агентствах [8.16], а аналогичный подход предложен Giga Group [8.17]. Основными элементами этой модели являются этапы выбора, контроля и оценки, как показано на рис. 5.3.

Рис. 5.3.  Основные этапы процесса управления инвестициями в ИТ
Целью модели является предоставление организациям систематизированного метода, позволяющего сократить возможные риски и добиться максимально возможного показателя возврата от инвестиций в ИТ. Следует, однако, отметить, что такие модели сами по себе описывают только "целевые характеристики" процессов управления инвестициями в ИТ, но не конкретные пути и методы их осуществления. Таким образом, конкретная реализация при интерпретации модели зрелости должна применяться в контексте особенностей данной организации.
Таблица 5.2 является сопоставительной для оценки зрелости процессов управления ИТ-активами и инвестициями в ИТ по работам [8.18], [8.16].

Таблица 5.2. Шкала оценки уровня управления ИТ-активамиУровеньУправление ИТ-активамиУправление инвестициями в ИТ

1. Хаос	В организации отсутствует информация по имеющимся ИТ-активам. Неиспользуемое оборудование хранится на складе и не контролируется ответственными сотрудниками (речь идет об учете и контроле со стороны ИТ-службы: все оборудование, как правило, в любом случае учитывается в бухгалтерии и "числится" на материально-ответственном лице). В организации отсутствует централизованная служба закупок, они осуществляются подразделениями по мере надобности. Системы учета контрактов на закупку не существует, а сами договоры на поставку хранятся в картонных папках. Нет системы учета интеллектуального капитала организации и стратегии закупок. Отсутствует документированная ответственность за управление ИТ-активами	На предприятии нет общего понимания необходимости организации управления инвестициями в ИТ как процесса, равно как и методов управления инвестициями. Фактически применяемые процедуры обоснования проектов являются специально создаваемыми и могут изменяться от проекта к проекту. Отсутствует единая система измерения показателей эффективности достигаемых результатов. Процессы выбора проектов недетерминированы, а их эффективность непредсказуема
2. Реактивный	Для учета активов используются базы данных или электронные таблицы. Часть оборудования может идентифицироваться с применением автоматизированных средств. Однако такие процедуры, как установка, перемещение, изменение конфигурации отслеживаются далеко не всегда, тем самым данные теряют актуальность и точность. Отчеты служат только для перечисления активов и получения сводных величин, но не используются для выделения проблемных областей. Инвентаризация производится нерегулярно. Лицензии на программное обеспечение рассматриваются в отрыве от аппаратных средств. Данные по существующим активам только спорадически используются при планировании новых закупок	Методы инвестиционного управления четко определены и последовательно используются во всех реализуемых проектах. Произведена инвентаризация всех ИТ-активов. В организации созданы Советы по инвестициям в ИТ
3. Проактивный	Процессы управления активами четко определены и охватывают все этапы жизненного цикла. Существующая база данных по учету активов доступна для использования сервисной службой и интегрирована со средствами автоматической идентификации, а также связана с базой данных по контрактам. Это позволяет осуществлять оценку эффективности использования ресурса. Организация закупок осуществляется выделенной группой под руководством выделенного менеджера, подотчетного руководителю ИТ-службы и финансовой службе. Процессы управления пересматриваются при необходимости в установленном порядке	Все выполняемые проекты собраны в согласованный и сбалансированный портфель инвестиций в информационные технологии. Состав портфеля увязан с целями организации, стратегии их достижения – с определением получаемых преимуществ и критериев риска, а также с финансовыми возможностями компании
4. Сервисный	В дополнение к предыдущему уровню, эффективность процессов постоянно измеряется на основе количественных метрик, например, на основе TCO. Результаты постоянно проводимого анализа регулярно доводятся до сведения бизнес-подразделений для возможной оптимизации. Процессы закупок автоматизированы и интегрированы в общую логистическую цепочку организации. Используются средства оптимизации объемов закупок и содержимого склада	Управление инвестиционным портфелем организации обеспечивается путем последовательной оценки эффективности проектов и развития методов выбора проектов и оценки эффективности. Критичным элементом является проведение объективной оценки эффективности инвестиций после завершения проекта, в том числе относительно выполнения планов и ожиданий по получаемым выгодам. Эти результаты используются для оперативной корректировки текущего портфеля проектов
5. Оптимизированный	Управление ИТ-активами полностью интегрировано в управление всеми активами предприятия с учетом их специфики. Использование активов учитывается как расходы бизнес-подразделений. Оно непосредственно связано с оценкой эффективности и стоимости труда персонала	Мониторинг инвестиций в ИТ и методы управления распространяются на формирование и поддержку стратегических бизнес-результатов. Осуществляется постоянное сравнение существующих процедур и методов с лучшими практиками и конкурентами

<
По оценкам Gartner, на первых трех уровнях находятся соответственно порядка 30%, 45% и 20% организаций, а на 5-м уровне – только единичные организации. С другой стороны, внедрение средств управления активами позволяет обычно сэкономить до 30% стоимости активов в первый год и от 5 до 10% – в каждый последующий.

А к какому уровню зрелости можно отнести эти два процесса в известных вам организациях?

Эта модель управления инвестициями в ИТ, предложенная GAO (Финансово-контрольное управление США), строится таким образом, что каждая последующая стадия достигается путем использования предыдущей стадии в качестве "фундамента" и реализации определенных рекомендаций – так называемых "критических активностей". При этом каждая из пяти стадий зрелости, кроме первой, характеризуется определенным набором "критических" процессов, содержание которых по мере продвижения по стадиям меняется. Например, на стадии 2 определяются такие критические процессы, как "Деятельность Совета по инвестициям в ИТ", "Надзор за ИТ-проектами", "Управление ИТ-активами", "Идентификация потребностей бизнеса для ИТ – проектов" и "Выбор проектов для реализации".

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


Рис. 5.4.  Основные элементы критического процесса по управлению ИТ-активами

ИТ - стратегия

Организационные и системные отличия и проблемы

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

Рис. 6.2.  Модель деятельности государственных ведомств
Заметим, что государственный сектор наиболее подвержен рискам неэффективных решений, а отсутствие архитектуры и четкой стратегии становятся особо заметными. Мы уже отмечали, что, по данным американского Центра правительственных технологий, статистика провалов проектов в области ИТ в госсекторе в среднем составляет порядка 70–80% от общего числа по сравнению со значением 54% по всем отраслям в целом. При этом около трети неудач связаны с проблемами и недостатками проектирования архитектуры.
В частности, в 2004 финансовом году, по данным Административно-бюджетного управления США, 17 из 26-ти обследованных федеральных агентств и более половины из основных 1400 ИТ-проектов находились в области риска, более половины из 230-ти федеральных программ не могли продемонстрировать реальный эффект, а еще 20% оказались неэффективными.
Причина неудач, по мнению экспертов, как правило, кроется в неадекватной оценке сложности решения, а также в отсутствии полноценного осознания того влияния, которое новая технология будет оказывать на все аспекты работы организации. Две глобальные ошибки, совершаемые "ответственными" чиновниками, это либо неправильный выбор технологии, либо неправильное внедрение в принципе адекватно подобранного решения.
Эти две "фатальные", в конечном счете, ошибки формируются из ряда мелких недочетов в ходе работы, например:

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

система разрабатывается без привлечения к этому процессу ее будущих пользователей;

система разрабатывается без учета реальных условий работы;

система разрабатывается без учета работы других систем;

система разрабатывается "одновременно" несколькими ведущими, конкурирующими между собой ведомствами;

в бюджет не закладывается стоимость "доводки" решения после внедрения.

К числу объективных факторов, обусловливающих такие негативные результаты, относятся:

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

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

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

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

Особенности использования понятия

Решение, которое государство находит для проблемы, обычно является таким же плохим, как сама проблема.
Милтон Фридман
Ежели таковых областей, в коих градоначальники станут второго сорта законы сочинять, явится изрядное количество, то не произойдет ли от сего некоторого для архитектуры Российской Державы повреждения?
М. Е. Салтыков-Щедрин. "История одного города"
В конце XX-го – начале XXI-го века многие государства мира стали смотреть на информационные технологии как на способ решения проблем, стоящих перед ними. Однако, в соответствии с приведенной выше цитатой одного из величайших экономистов XX-го века Милтона Фридмана, очень часто подход к решению проблем государства с помощью ИТ оказывался таким же плохим, как сами проблемы. Именно с этим связаны, в частности, существенные трудности реализации многих национальных и ведомственных инициатив в области "электронного правительства". И дело оказалось не в том, что технологии плохи. Очень часто одной из ключевых причин проблем было и остается отсутствие такой системообразующей компоненты, как архитектура. А то, что архитектура государства – вещь важная, как мы видим, осознавали еще классики русской литературы.
Все, о чем мы до сих пор говорили, относилось к корпоративной архитектуре уровня предприятия. По большому счету, государство есть совокупность ведомств, которые составляют некоторую "корпорацию", называемую государством. Возникает вопрос: "А нужно ли в таком случае рассматривать отдельно проблему формирования архитектуры информационных технологий государства в целом или архитектуру отдельного региона, города?" Ответ, однако, однозначно положительный – нужно. Тут мы снова имеем типичную ситуацию, когда "целое составляет нечто большее, чем механическая сумма составляющих" [9.1].
Итак, государство как институт обладает уникальными свойствами, которые отсутствуют у отдельных ведомств как составных элементов системы под названием "государство". Это стало особенно очевидно, когда в рамках национальных и региональных инициатив в области создания "электронных правительств" встала задача предоставления государством интегрированных услуг гражданам и хозяйствующим субъектам по принципу "одного окна". Поэтому эта лекция адресована в равной степени тем, кто имеет отношение к проектам внедрения ИТ (или же, как более принято называть в отечественной литературе – информационно-коммуникационных технологий – ИКТ) как на национальном уровне, так и на уровне региона или города.
Если применять понятие "Архитектура предприятия" в отношении государства (правительства) на национальном, региональном уровне, уровне крупного муниципалитета, то термин "предприятие" (или "корпорация") с практической точки зрения означает совокупность министерств, ведомств, агентств, служб, которые взаимодействуют друг с другом и чьи бизнес-процессы (административные процессы) имеют общие характеристики. При этом ведомства в рамках такого обобщенного "предприятия" также взаимодействуют с внешними субъектами: гражданами, хозяйствующими субъектами и другими государственными ведомствами. Эти взаимодействия все чаще осуществляются в электронной форме, поэтому требуются общие стандарты на информационные технологии, которые применялись бы в масштабах всего правительства соответствующего уровня как единого "предприятия", для того чтобы обеспечить целостность, надежность и гибкость выполнения государственных функций.
Поскольку термин "предприятие" в отечественной практике государственного управления мало приемлем и может неоднозначно пониматься, то наиболее адекватным аналогом понятия "Архитектура предприятия" в отношении государства и правительства соответствующего уровня является понятие "Архитектуры электронного правительства" (или "Архитектура электронного государства", "Федеральная архитектура", "Архитектура электронного региона", "Архитектура электронного города" – в зависимости от того, о каком уровне государственного управления идет речь).
Разумеется, отдельные государственные ведомства и организации могут использовать термин "Архитектура предприятия" в отношении описания собственной архитектуры, описывающей все направления деятельности внутри конкретной организации. В данном разделе мы говорим об особенностях интегрированной архитектуры электронного правительства в целом, поскольку подходы к применению архитектурных подходов на уровне ведомств очень близки к тем, которые были нами описаны для архитектуры предприятий в отношении отдельных организаций вообще.
При этом, хотя мы и будем использовать термин "Архитектура электронного правительства", здесь фактически речь идет не только о проектах в области "электронного правительства" как такового (электронные услуги для граждан и бизнеса), а об архитектуре всех информационных технологий правительства соответствующего уровня, включая "услуги" для самих государственных служащих.
По большому счету, то, что уже было сделано в плане создания ИТ-систем на уровне отдельных, наиболее передовых в плане использования информационных технологий ведомств в течение последних десяти и более лет, должно быть сделано на уровне государства, а это требует системного, "корпоративного" взгляда на деятельность государства и правительства и, соответственно, разработки архитектуры электронного правительства в целом.
Архитектура электронного правительства представляет интерес еще и по следующей прагматической причине. В отличие от коммерческих предприятий и корпораций, которые практически никогда не делают публичной информацию о своей архитектуре предприятия, методологиях и подходах ее разработки и использования, существует достаточно большое количество публичных материалов в открытом доступе в Интернете, с описанием методик разработки архитектуры, которые использовали те или иные государства на национальном и региональном уровнях. Доступно большое количество материалов с описанием конкретных разработанных архитектур, "как они есть" и "как они должны быть".
Эти документы и эта информация имеют универсальную ценность и применимость независимо от того, идет ли речь о коммерческой компании, государстве в целом, региональном правительстве или правительстве крупного муниципалитета. С нашей точки зрения, они уникальны по своему содержанию, в них отражена, например, практика описания архитектур и методики консалтинговых компаний, таких как Gartner Group, Meta Group, т.е. информация, получение которой иными способами потребовало бы весьма ощутимых финансовых затрат.
Поэтому мы настоятельно рекомендуем всем читателям просмотреть разделы, посвященные примерам проектов разработки и реализации архитектуры электронного правительства национального уровня, а также регионального уровня и уровня крупного города и, особенно, приведенные там ссылки на ресурсы Интернета, где можно найти подробные документы, описывающие соответствующие архитектуры и методики их разработки.
Если кратко, то государство отличается от корпораций (и даже крупных корпораций) тремя аспектами:

масштабом;

интересами и целями;

принципами распределения ответственности и влияния.

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

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

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


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

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

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

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

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

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

В последние годы появилась литература на русском языке, в которой содержится достаточно обширный материал по тематике архитектуры электронного правительства, большей частью основанный на зарубежном опыте таких стран, как США, Великобритания, Германия и ряд других [9.2], [9.3], [9.4], [9.5]. Несравненно большее количество публичной информации доступно на английском языке в Интернете. Соответствующие указания можно найти в Приложении в разделе "Ресурсы и полезные ссылки". Кроме того, достаточно важной отдельной областью, которая требует своего специального анализа и по которой также существуют обширные публикации, являются сравнительные оценки различных стран в области реализации "электронного правительства" и оценки готовности (readiness) к реализации таких проектов и к информационному обществу в целом. К сожалению, Россия пока, по разным критериям, занимает 50-70-е места в этих списках.

Мы же остановимся на вопросах, которые практически не отражены в литературе на русском языке:

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

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

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

Использование единых принципов и стандартов разработки архитектуры государственных организаций и архитектуры электронного правительства должно выполнять двуединую роль:

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

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

При этом разработка архитектуры электронного государства на национальном уровне условно делится на две составляющие:

Разработка методологии описания архитектуры. Эта методология либо явно разрабатывается и формулируется, как это сделано в США в форме методологии Федеральной архитектуры, либо эта методология существует как бы неявно, но проявляется, в конечном итоге, в форме набора документов, описывающих различные аспекты архитектуры электронного правительства и заложенных в них принципов. Данная методология чаще всего создается не на пустом месте, а на основе других методик. Так, например, в Германии за основу взята Справочная Модель Открытых Распределенных Вычислений (RM-ODP – Reference Model of Open Distributed Processing) [9.6]. Как правило, разработка собственных методик реализуется на национальном уровне, для того чтобы, во-первых, учесть национальную специфику государственного устройства, уровень и характер используемых технологий, а во-вторых, обеспечить ведомствам, региональным и местным органам общие подходы и правила разработки собственных архитектур;

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

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

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

Отличия в критериях эффективности использования ИКТ

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

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

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

Политический эффект. То есть, это не традиционный возврат от инвестиций (ROI), а "политический возврат от инвестиций" (PROI – Political Return on Investment). Архитектура должна обеспечивать синхронизацию и выравнивание возможностей, предоставляемых информационными технологиями для реализации миссии, достижения целей и задач, сформулированных политическим руководством.

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

Проблема масштаба

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

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

выполнение 5 млрд. различных транзакций ежегодно;

наличие 20 крупных ведомств (министерств) на национальном уровне;

более 200 меньших по размерам государственных агентств и организаций;

480 местных органов власти и управления.

Далеко не каждая крупная коммерческая компания сталкивается с организационно-техническими проблемами такого масштаба. При этом большинство коммерческих компаний имеют обычно не более 10 (в среднем около 6) различных бизнес-процессов, которые включают в себя определенное количество подпроцессов [9.7]. Сколько же бизнес-процессов у государства?
На федеральном уровне Правительство США идентифицировало 487 бизнес-процессов (из них – 28 ключевых, укрупненных процессов). При этом надо заметить, что до недавнего времени госорганизации уделяли непростительно мало внимания анализу своих бизнес-процессов, в то время как реинжиниринг бизнес-процессов – горячая тема с начала 1990-х г.г. Приведем следующую цитату: "Обеспечение тесного соответствия (синхронизации) между ключевыми бизнес-процессами и ИТ-архитектурой является единственной наиболее важной работой по правильному созданию архитектуры" [9.8].
В России только сейчас, в связи с обсуждением административных регламентов, электронных административных регламентов и необходимости принятия соответствующего федерального закона, функциональный взгляд, основанный на анализе государственных бизнес-процессов, начинает получать адекватное внимание специалистов в области государственного управления.

Проблема сроков реализации проектов и инкрементальной автоматизации

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

Проблема управления и контроля использования архитектуры (governance)

Процесс разработки архитектуры и впоследствии обеспечение ее практической реализации является непростым и для больших коммерческих компаний, а в условиях распределения областей ответственности, фрагментарности организационных структур, характерных для правительства любого уровня управления, он становится сложней на порядок.
Практика показывает, что государственные организации испытывают трудности при разработке и практическом использовании архитектуры в большей степени, чем коммерческие компании. Очень часто усилия по разработке архитектуры заканчиваются созданием обширного количества не используемых на практике документов, усугубляя и без этого непростую ситуацию с объемом бумажной работы в государственных организациях.
Реальная ценность архитектуры электронного правительства, если мы говорим о национальном или региональном уровне, и архитектуры предприятия, если мы говорим об уровне отдельного ведомства, состоит в использовании этой архитектуры при реализации отдельных инициатив, проектов и программ. Люди, отвечающие за реализацию отдельных государственных инициатив или за информационные технологии в отдельных ведомствах, как правило, обладают большой степенью свободы в принятии решений. Поэтому критическим фактором для успеха или неудачи практики разработки и использования архитектуры являются соответствующие организационные механизмы контроля использования и развития архитектуры.
В этом отношении имеется положительный опыт федерального правительства США, когда применение Федеральной архитектуры, о которой речь пойдет ниже, подкреплено соответствующими законодательными и нормативными документами. При этом процесс организован так, что запросы на бюджетное финансирование, связанные с информационными технологиями, оцениваются на соответствие Федеральной архитектуре.
В конечном итоге, архитектура должна направлять процессы организационных изменений. При этом следует учитывать, что государственные служащие, как группа, в силу объективных причин более консервативны в плане реализации изменений, чем их коллеги в коммерческих компаниях. Два фактора определяют поведение и деятельность государственных ведомств в первую очередь: 1) законы и другие нормативные акты, и 2) бюджетный процесс. Для обеспечения успеха архитектуры необходимо умело использовать оба эти фактора.

Разница в целях государственных и коммерческих организаций

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

ИТ - стратегия

Архитектура общих сервисов

Общие сервисы являются критически важной областью при реализации государственных программ информатизации и инициатив электронного правительства на национальном, региональном уровне и уровнях крупных муниципалитетов. Именно реализация общих сервисов может принести максимальную пользу от разработки или использования архитектурных подходов в проектах электронного правительства, поэтому мы здесь уделим им особое внимание.
Общие сервисы занимают положение в "средней части" архитектуры электронного правительства. Они обеспечивают необходимую поддержку одновременно для нескольких областей архитектуры и при этом, как правило, не содержат в себе какую-либо специфическую бизнес-логику, характерную для отдельной предметной области деятельности государственных ведомств. Например, единый государственный сервис электронных платежей может быть использован самыми различными государственными ведомствами и их информационными системами для сбора штрафов, оплаты получения определенных справок (оказание государством услуг) или сбора налогов.
Централизованная реализация этих общих сервисов может обеспечить для государства существенные выигрыши в плане операционной эффективности, но только в том случае, когда отдельные ведомства или территориальные органы государственного управления используют преимущества таких общих сервисов, а не дублируют их создание на своем уровне.
Общим сервисам уделяется существенное внимание в методике описания архитектуры электронного правительства Gartner, а также в таких методиках, как SAGA Федерального Правительства Германии и e-GIF Правительства Великобритании.
Когда мы говорим об общих сервисах (или компонентах), то можно выделить:

централизованно спроектированные, но внедряемые локально общие сервисы;

централизованно спроектированные и централизованно внедряемые общие сервисы.

При этом можно назвать две крупные категории общих сервисов [9.11]:

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

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

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

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

Информационное взаимодействие с гражданами и бизнесом:

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

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

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

Транзакционные процессы:

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

Процессы поставок:

Системы электронных закупок. Эта система может обеспечивать все этапы процесса закупок продуктов и услуг в интересах ведомств с обеспечением реализации всех необходимых правил и законов;

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

Корпоративные процессы:

Финансовые и бухгалтерские системы;

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

Системы управления персоналом;

Системы обучения персонала.

Специализированные процессы:

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

Следующие общие сервисы и системы можно отнести к категории обеспечивающих:

Многократно используемые инфраструктурные компоненты:

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

Сервисы каталогов. Этот сервис может обеспечивать, например, единый, основанный на стандарте X.500 каталог с адресной информацией, телефонами, адресами электронной почты служащих и т.д. в интересах всех государственных ведомств;

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

Информационные сервисы:

регистр населения;

регистр хозяйствующих субъектов;

регистр объектов недвижимости;

земельный кадастр;

геоинформационные системы;

системы поддержки принятия решений.

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

Для успеха в реализации общих сервисов государство должно учитывать следующие четыре фактора:

Как выбрать и обосновать реализацию тех или иных сервисов в качестве общих?

Какую модель выбрать для реализации общих сервисов (организационные и прочие вопросы)?

Как обеспечить переход ведомств на использование общих сервисов?

Как обеспечить процессы улучшений в реализации и использовании общих сервисов?

Для ускорения процессов использования общих сервисов государство, ведомства и поставщики соответствующих сервисов могут придерживаться следующих рекомендаций [9.12]:

продвижение общих для государства (региона стандартов) на электронные сообщения и документы (например, в форме утвержденных XML-схем);

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

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

использование стандартов web-сервисов;

принятие единых стандартов безопасности на информационный обмен;

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

Общие сервисы являются первыми кандидатами на аутсорсинг этой части государственной инфраструктуры ИКТ.

Федеративная или централизованно-децентрализованная модель архитектуры

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

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

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

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

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

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

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

хорошо определенная архитектура;

общие методики;

общие форматы и схемы данных.

Общее описание Архитектуры электронного правительства

Вспомним традиционное разбиение архитектуры на представления или частные архитектуры (домены), такие как бизнес-архитектура, архитектура информации, архитектура приложений и технологическая архитектура. Государство в целом и отдельные ведомства, на самом деле, имеют много общего, когда мы рассматриваем "нижние" уровни: инфраструктуру, вычислительные платформы и сети. Эти базовые уровни не несут и не отражают специфику, связанную с логикой деятельности организации и выполнения функций и бизнес-процессов. Однако очевидные различия с коммерческими предприятиями обнаруживаются по мере того, как мы рассматриваем "более верхние" слои стека информационных технологий, которые связаны с прикладными системами для исполнения конкретных государственных функций. Государственные ведомства отвечают за реализацию характерных для государства функций, и среди этих функций можно найти лишь небольшое число параллелей и аналогий с коммерческими организациями. Государственные ведомства также внедряют такие корпоративные системы, как системы управления ресурсами предприятия (ERP) или системы управления отношениями с клиентами, т.е. гражданами и бизнесом (CRM). Но даже при условии, что эти системы реализуют аналогичные функции, что и в бизнес-среде, реализация их в государственных ведомствах сильно отличается.
Если говорить об отличиях, связанных с выделением отдельных представлений (или доменов) в описании Архитектуры электронного правительства, то многие методики особо выделяют некоторые области, которые не всегда актуальны для архитектуры уровня предприятия.
В качестве примера можно привести концепцию Архитектуры электронного правительства Gartner [9.9], которая выделяет следующие представления:

интерфейс;

бизнес-архитектура (функции);

данные;

прикладные системы;

общие сервисы;

интеграция;

инфраструктура.

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

Рис. 7.1.  Концептуальная архитектура электронного правительства
Заметим, что данная концептуальная архитектура электронного правительства Gartner была опубликована еще в 2001 году и носит достаточно "традиционный" характер. В курсе "Архитектура предприятия" мы описывали несколько иную методику Gartner Group для описания архитектуры предприятия, которая впервые была опубликована в 2002 году. Она также применима к электронному правительству, и чуть позже мы рассмотрим особенности использования этой обновленной методики в отношении электронного правительства.
Сейчас нам, однако, важнее понять особенности различных доменов архитектуры применительно к электронному правительству. В частности, можно заметить такую характерную, в основном, только для архитектуры электронного правительства область (домен), как общие сервисы. Но и многие другие области архитектуры электронного правительства также содержат характерные особенности, на которых мы кратко остановимся.
Рассмотрим более подробно особенности архитектуры электронного правительства в целом и отличительные черты отдельных доменов (областей) этой архитектуры.

Особенности архитектуры государственных функций (бизнес-архитектуры)

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

Большое количество аналогичных или очень близких по формам реализации услуг, предоставляемых различными ведомствами. Например, в Германии почти 3/4 всех услуг федерального правительства (73%) принадлежат к услугам трех типов: "Сбор, обработка и предоставление общей и специализированной информации", "Общие процедуры обработки заявлений, поступающих в государственные ведомства", "Процедуры оказания содействия и помощи";

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

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

Особенности архитектуры интеграции электронного правительства

Сложность проблемы интеграции информационных систем трудно переоценить. По оценкам аналитической компании ZapThink, до 70% процентов ИТ-бюджетов сегодня тратится на решение вопросов интеграции. При этом количество неудачных интеграционных проектов превышает количество успешных. Так, по оценкам Forrester Research, только 35% проектов по интеграции завершается в срок и в соответствии с бюджетом [9.13].
На уровне государства в целом, региона или крупного муниципалитета эта ситуация, как мы отмечали, носит особенно драматичный характер в силу необходимости интеграции большого количества информационных систем, принадлежащих различным ведомствам.
Поэтому явное выделение в архитектуре электронного правительства в качестве отдельного представления (домена) архитектуры интеграции (включая архитектуру программного обеспечения промежуточного слоя) носит обоснованный характер.
Основными барьерами в межведомственной интеграции процессов, систем и услуг являются прежде всего не технические проблемы, а юридические, политические, организационные и процедурные. Поэтому жесткое навязывание единой технологии, внедрение решений "одним махом" по указанию сверху всегда встречают сопротивление ведомств и органов власти регионального и местного уровней.
Единственный способ решения этих проблем в реальных условиях работы государства – использование федеративного подхода, когда ведомства и регионы продолжают использовать свои собственные технологические решения плюс некоторое количество общих сервисов, а также единую инфраструктуру, обеспечивающую информационный обмен между ведомственными системами в формате электронных сообщений согласованных XML-форматов.
Этот подход обеспечивает быструю реализацию общих для правительства соответствующего уровня процессов без необходимости отдельным ведомствам отказываться от своих имеющихся систем и менять их на новые, "великие и идеальные" системы, разрабатываемые централизованно. Это также уменьшает требования, которые предъявляются к государственным служащим и ИТ-специалистам с точки зрения обязательного понимания в деталях общей картины всех государственных информационных систем для реализации новых сервисов в электронной форме.
Большое количество стран на национальном уровне пошли именно по этому пути и создали соответствующую основу архитектуры интеграции в форме инфраструктуры, для которой используются в разных странах такие названия, как "правительственный шлюз" (Великобритания, Чехия, Болгария Румыния), "Брокер Государственных Сервисов" (PSB – Public Services Broker) в Ирландии и т.д. По большому счету, все эти решения основываются на принципах сервисной шины (в терминологии сервис-ориентированной архитектуры), на использовании интеграционного ПО пересылки сообщений (MOM – Message Oriented Middleware), согласованных схемах XML-сообщений.
Дополнительную информацию по архитектуре интеграции электронного правительства вообще и по ее практической реализации в Великобритании можно найти в [9.14].

Особенности домена данных в архитектуре электронного правительства

Использование единых технологических стандартов является необходимым, но не достаточным условием для обеспечения взаимодействия между прикладными системами различных ведомств. Технологии, как таковые, не создают единой грамматики и семантики данных. В то же время интеграция прикладных систем требует именно общей семантики для того, чтобы был обеспечен обмен данными между системами. Основу этого составляют общие схемы и единые определения элементарных типов данных.
В проектах электронного правительства имеется большое количество вовлеченных сторон (акторов) – ведомств и организаций – при этом взаимодействие и коммуникационные связи между ними весьма разнообразны, поэтому процесс достижения соглашений о соответствующих схемах данных становится исключительно сложным. Тем не менее именно данные служат, пожалуй, основой как для реализации государственных информационных систем (что не является чем-то исключительным для любого сектора в принципе), так и для их интеграции, что для государства – особенно сложная задача.
Дело в том, что ключевые государственные информационные системы должны эксплуатироваться десятилетиями, в то время как цикл использования информационных технологий и отдельных продуктов измеряется годами. Персональные компьютеры устаревают за 3 года; для таких бэк-офисных систем, как базы данных, жизненный цикл составляет 2-5 лет (после чего требуется сложный процесс обновления); языки программирования и другие элементы системной архитектуры (клиент/сервер, web-браузеры) "живут" примерно 10 лет. Напротив, в соответствии с законодательством, требуемый срок хранения данных по персоналу составляет 75 лет, а некоторые данные вообще должны храниться вечно.
Поэтому единственная долговременная основа для создания и последующей интеграции государственных информационных систем – это структуры данных. Независимо от того, что случится с технологиями, люди будут получать сертификаты о рождении и паспорта, водительские удостоверения, будут работать и платить налоги, получать медицинское обслуживание, жениться, строить дома и покупать квартиры, создавать компании; будут, к сожалению, умирать. Поэтому именно данные должны закладывать основу инфраструктуры электронного правительства.
К счастью, в настоящее время имеется консенсус по поводу лучшего способа обмена информацией – это XML. Можно сказать более того: XML является основой представления процессов, услуг и документов электронного правительства, потому что:

он является открытым: им "не владеет" ни одна организация;

он является "прозрачным" в том плане, что может читаться людьми и машинами;

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

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

Особенности процесса реализации архитектуры электронного правительства

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

Рис. 7.2.  Этапы реализации Архитектуры электронного правительства
Заметим, что хотя этапы логически представлены в последовательной манере, на практике каждый из них начинается и реализуется еще до окончания предыдущего. Эти три этапа условно можно назвать так:

фаза построения основ;

фаза создания общих правительственных информационных систем (в английском языке используется термин "корпоративная фаза" – Enterprise phase);

фаза реализации специфических для ведомств и агентств проектов и систем.

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

вычислительная инфраструктура: центры обработки данных, серверы, сети, настольные системы и т.д.;

коммуникационная инфраструктура для передачи данных, голоса, видео, ТВ;

основные сервисы, обеспечивающие продуктивность работы персонала: текстовые редакторы, электронная почта, телефонная связь, удаленный доступ и т.д.;

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

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

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

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

Примерами систем, которые создаются на этой фазе, являются:

финансово-бюджетные системы;

геоинформационные системы;

центральные регистры и кадастры (населения, собственность, земля).

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

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

Уровень интерфейса с клиентами

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

ИТ - стратегия

Архитектура взаимодействия электронного правительства Великобритании (e-GIF)

Архитектура взаимодействия электронного правительства (e-GIF – e-Government Interoperability Framework) устанавливает государственные технические политики и спецификации с целью достижения высокого уровня интеграции и взаимодействия информационных систем государственного сектора Великобритании. В апреле 2004 года опубликована уже шестая версия этой архитектуры [9.17]. Оригинальные документы можно найти по адресу http://www.e-envoy.gov.uk Офиса e-Envoy, который отвечает за проект электронного правительства Великобритании.
По подходам, основанным на сочетании централизованных механизмов управления национальными инициативами в области электронного правительства и децентрализованной реализации, принципы, заложенные в e-GIF в Великобритании близки к тем, которые мы увидели в Германии, хотя сами наборы документов и методики сильно отличаются.
Так, e-GIF описывает те спецификации, которые важны с точки зрения взаимодействия систем, интеграции данных, доступа к государственным услугам в электронной форме, управления государственным контентом и метаданными. В этом отношении использование ведомствами политик и спецификаций e-GIF является обязательным. Они задают базовую инфраструктуру, применение которой освобождает государственные ведомства от этой части работы и позволяет им сконцентрироваться на предоставлении услуг потребителям. Это все те же общие сервисы, или базовые компоненты в немецкой терминологии.
Ответственностью самих ведомств является анализ и оптимизация собственных бизнес-процессов и получение преимуществ от общих принципов и инфраструктуры интеграции.
При этом e-GIF служит рамочным документом, который содержит высокоуровневые утверждения, описания технических политик и принципов управления, общие описания процессов внедрения и следования принципам e-GIF. Он дополняется рядом других документов, которые в совокупности описывают видение Архитектуры электронного правительства Великобритании:

Стандарт на метаданные электронного правительства (e-GMS – e-government Metadata Standard). Основан на так называемом Дублинском ядре и нужен, в частности, для стандартного описания всей информации, публикуемой государственными ведомствами, например, на государственных порталах.

Список Категорий Правительственной информации (GCL – Government Category List). Просмотр категорий информации является, как правило, первым инструментом поиска, поэтому целесообразно иметь государственные стандарты в этой области.

Каталог Стандартных Государственных Данных (GDSC – Government Data Standards Catalogue). Этот Каталог описывает элементы и типы данных, которые используются, например, в "Общей Информационной Модели Государственной Услуги", описанной в e-SDF (см. ниже), и в Справочной Модели Сообщений, определяющей форматы стандартных сообщений, которыми обмениваются государственные информационные системы. Каталог обеспечивает связь между функциональными требованиями с точки зрения описания услуг ("Общая Информационная Модель Государственных Услуг") и техническим описанием с точки зрения практической реализации (Справочная Модель Сообщений). По большому счету, Каталог Стандартных Государственных Данных описывает имена различных элементов (тэгов), используемых в различных государственных XML-документах (например, как будут именоваться тэги, используемые для описания "Фамилии", "Имени" гражданина, элементов адреса места жительства и пр.), какие типы данных при этом и меются в виду (текстовые, числовые и пр., а также их формат).

XML-схемы. XML и XSL рассматриваются в качестве ключевых стандартов для интеграции и управления данными. Это включает механизмы централизованного согласования, создания и определения XML-схем, которые используются всеми государственными ведомствами.

Каталог Технических Стандартов (TSC – Technical Standards Catalogue). Определяет технические стандарты и спецификации в четырех областях: взаимодействие систем, интеграция данных, метаданные управления контентом и доступ к электронным услугам. Это минимальный набор стандартов, которые требуются для обеспечения широкого спектра транзакций и услуг, предоставляемых государством, и для интеграции государственных информационных систем.

Методика разработки электронных услуг (e-SDF – e-Services Development Framework). Содержит методики описания и разработки электронных государственных услуг, в том числе с применением конструкций языка UML, параметры стандартной модели сервисного взаимодействия государства и гражданина в процессе предоставления услуги, высокоуровневую архитектуру информации, которая включает Общую Информационную Модель Государственной услуги и Справочную Модель Сообщений.

Совокупность документов, определяющих архитектуру электронного правительства Великобритании, представлена на рисунке 9.6.


Рис. 8.6.  Структура областей описания архитектуры электронного правительства Великобритании

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

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

Методика FEAF Федеральной Архитектуры США

В первую очередь при обсуждении методологий, которые изначально разрабатывались с учетом специфики государства, следует отметить методику Федеральной Архитектуры США (FEAF – Federal Enterprise Architecture Framework). Эта методика отличается высокой степенью комплексности политики, процессов и моделей, что отражает исторические традиции и уровень использования ИКТ в деятельности американского правительства. Методология FEAF рассматривается в качестве ориентира и многими европейскими странами, и Евросоюзом в целом. Оригинальные документы, описывающие методологию FEAF, представлены на сайте Офиса Управления Проектом Разработки Федеральной Архитектуры США (FEAPMO – Federal Enterprise Architecture Project Management Office) www.whitehouse.gov/omb/egov. Достаточно подробное описание методики FEAF на русском языке можно найти в книгах [9.2], [9.3], [9.4]. Здесь мы отметим только самые главные моменты.
Совет руководителей информационных служб (CIO Council) начал разработку FEAF в апреле 1998 году. В основу был положен Стратегический план деятельности CIO Council, разработанный с учетом приоритетов Закона по реформированию системы управления информационными технологиями в органах государственной власти принятого в 1996 году (Information Technology Management Reform Act или, иначе, закон Клингера-Кохена), который определял направления разработки и использования Федеральной Архитектуры для максимизации отдачи от использования ИКТ в государстве под флагом "эффективности инвестиций денег налогоплательщиков в ИТ". Этот закон определил в качестве одной из обязанностей руководителей департаментов информационных технологий государственных ведомств разработку архитектуры информационных технологий.
Офис FEAPMO дает следующее определение Федеральной Архитектуры:
"Федеральная Архитектура – это концептуальная модель описания в координированной, структурированной форме деятельности федерального правительства и государственных организаций с функциональной точки зрения, вне зависимости от организационных структур, реализующих соответствующие функции, с целью улучшения их деятельности за счет использования информационных технологий".
По сути дела, это новый способ описания, анализа и улучшения деятельности государства и госорганизаций, а также расширения их возможностей по обслуживанию граждан. Федеральная Архитектура – это стратегический информационный актив, который определяет функции (бизнес) государственных организаций, информацию и технологии, необходимые для реализации функций, а также процессы преобразований, необходимые для внедрения новых информационных технологий в ответ на изменяющиеся бизнес-потребности. Отдельные государственные организации должны использовать эту общую модель для описания своих собственных архитектур.
Важной особенностью проекта Федеральной Архитектуры США является функциональный подход к описанию архитектуры, т.е. подход со стороны бизнес-процессов, а не структуры федерального правительства и госорганов. В то же время следует отметить, что в рамках FEAF модели государственных функций приводятся только для задания контекста, т.е. в рамках FEAF не производится переопределения и детализации функций отдельных агентств. Эти справочные модели служат, по сути дела, определенными руководствами, которые обеспечивают общие архитектурные принципы при реализации межведомственных проектов, а также предоставляют всем государственным организациям единую методологию при разработке собственных архитектур.
Основной целью Федеральной Архитектуры является обеспечение условий для совместной разработки процессов, стандартов совместимости и обмена информацией между государственными органами и организациями.
FEAF состоит из следующих восьми компонент, которые кратко описаны ниже и представлены на рис. 8.1.

Рис. 8.1.  Методология Федеральной Архитектуры и ее компоненты

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

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

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

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

Стратегическое направление (Strategic Direction). Руководство для разработки целевой архитектуры (см. ниже), которое содержит видение, принципы, цели и объекты.

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

Текущая архитектура (Current Architecture). Определяет архитектуру "как есть" и состоит из двух частей:

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

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

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

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

Основные примеры переходных процессов включают следующие:

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

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

координация сегментов – координирование процесса интеграции архитектурных сегментов в единую Федеральную архитектуру;

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

управление активами – управление всеми активами, которые связаны с реализацией Федеральной архитектуры;

процессы закупок – согласование процессов закупок с архитектурой и с намеченными переходными процессами;

управление архитектурой – координация усилий по сопровождению и управлению архитектурой.

Архитектурные сегменты (Architectural Segments). Отражают разбиение общей архитектуры на отдельные, существенные области деятельности, например:

общие административные системы;

области федеральных программ, таких как внешняя торговля или предоставление грантов;

электронная торговля для проведения небольших закупок.

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

Каждый сегмент также характеризуется текущей и будущей архитектурой данного конкретного сегмента. Соответствующая информация и модели помещаются в базу данных (репозиторий) единой Федеральной архитектуры.

Архитектурные модели (Architectural Models). Определяют бизнес- и технологические модели, которые отражают все необходимые сегменты для полного описания архитектуры. Архитектурные модели задают бизнес-архитектуру и архитектуру информационных технологий.

При этом рассматриваются бизнес-модели и модели технической среды (данных, прикладных систем, технологий):

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

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

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

Соответственно, если говорить о том, какие представления (домены) выделяются в методике Федеральной архитектуры США, то они следующие:

бизнес-архитектура (функциональная архитектура деятельности правительства);

архитектура информации (данных);

архитектура приложений;

архитектура инфраструктуры (технологическая или системная архитектура): аппаратное и системное программное обеспечение, коммуникации.

В США ведется разработка и постоянное уточнение соответствующих взаимосвязанных так называемых Справочных (эталонных) Моделей (Reference Models) для каждой из перечисленных областей.


Иерархия Справочных Моделей в рамках Федеральной архитектуры показана на рис. 8.2. Эта иерархия включает в себя следующие модели:


Рис. 8.2.  Справочные модели Федеральной архитектуры США

Справочная модель эффективности (PRM – Performance Reference Model).

Справочная модель описания бизнеса федеральной организации (BRM – Business Reference Model).

Справочная модель сервисных компонент (SRM – Service Component Reference Model). Это описание компонент прикладных информационных систем, обеспечивающих реализацию государственных функций.

Справочная модель описания данных (DRM – Data Reference Model).

Технологическая справочная модель (TRM – Technology Reference Model).

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

Эти справочные модели являются, по сути дела, определенными руководствами, которые:

обеспечивают общие архитектурные принципы при реализации межведомственных проектов;

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

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

Методологии описания архитектуры, ориентированные на государственные ведомства

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

Методология Gartner для архитектуры электронного правительства

В курсе "Архитектура предприятия" мы описывали сформулированную относительно недавно методику описания архитектуры Gartner, которая представляет собой как бы трехмерный куб, состоящий из следующих элементов:

горизонтальные слои: Среда бизнес-взаимодействия, Стили бизнес-процессов, Шаблоны, "Строительные блоки" ("Кирпичики");

вертикальные домены: Приложения, Данные, Интеграция, Доступ;

вертикальные элементы технической архитектуры: Инфраструктура, Системное управление, Безопасность.

Следует отметить, что данное представление архитектуры вполне применимо для описания Архитектуры электронного правительства [9.9], [9.16].
Слой среды бизнес-взаимодействия описывает взаимодействие между государственными ведомствами и гражданами и/или бизнесом. Эта модель подчеркивает важность вопросов интеграции между различными ведомствами по горизонтали и вертикали. Внешняя среда, включая законодательство, изменения в экономике, новые вызовы в области безопасности определяют бизнес-стратегию государства и ведомств. Это все отражено на данном уровне.
Уровень стилей бизнес-процессов является тем уровнем, на котором бизнес-архитектура встречается с архитектурой технологий. Взаимодействие граждан и бизнеса с ведомствами и ведомств между собой характеризуется различными требованиями по времени отклика систем и методам взаимодействия.
Например, обработка информации о социальных услугах (предоставление бесплатной медицинской помощи или лекарств) может потребовать стиля создания информационных систем, основанных на обработке он-лайновых транзакций, в то время как предоставление ежемесячных сводок и отчетов может потребовать стиля пакетной обработки данных. Для обеспечения этих различных форм взаимодействия могут потребоваться различные логические шаблоны и технологии ("кирпичики"). Наличие этого слоя с различными стилями бизнес-процессов позволяет уйти от ситуации, когда с помощью какой-то одной технологии решаются самые разнообразные задачи, естественно, не оптимальным по соотношению цена/качество образом.
Слои среды бизнес-взаимодействия и стилей бизнес-процессов соответствуют сегменту бизнес-архитектуры электронного правительства.
Слой шаблонов задает логические шаблоны проектирования систем, которые обеспечивают идентифицированные ранее потребности во взаимодействии и стилях бизнес-процессов. Например, это может быть 4-уровневая архитектура приложений (клиент, презентационная логика, промежуточный слой, данные/"бэк-офис"). Либо же это будут различные шаблоны, используемые для обеспечения различных каналов взаимодействия граждан с государством и его информационными системами.
Слой "кирпичиков" ("строительных блоков") используется для описания применяемых сегодня и планируемых к применению в будущем технологических компонент, стандартов, продуктов. В качестве примера можно привести использование в системах браузера вместе с протоколом SSL для защищенного взаимодействия.
Традиционные архитектурные домены, такие как приложения, данные, интеграция и точки доступа пересекаются со слоями шаблонов и "кирпичиков". В свою очередь, эти четыре основных домена пересекаются "на заднем плане" с дисциплинами безопасности, системного управления и компонентами инфраструктуры.
Эта методика позволяет, в том числе и высшему руководству, отслеживать взаимосвязи между бизнес-потребностями государства и ведомств и выбранными технологиями. Методика также уделяет существенное внимание анализу различных стилей процессов, в том числе административных процессов и регламентов с используемыми шаблонами проектирования и технологиями.

Методология META Group в применении к описанию архитектуры электронного правительства

В лекции 5 мы рассматривали методику описания и разработки архитектуры, предложенную консалтинговой компанией META Group. Данная лекция содержит ссылки на источники информации, содержащие документы, которые описывают практический опыт разработки архитектуры органами государственного управления различных уровней.
Случайно или нет, но большое количество публично доступной информации о проектах регионального уровня (уровня отдельных штатов США) связано с использованием методики META Group. Эти материалы могут использоваться как наглядные пособия, описывающие саму методику и ее практическое применение.
Следует отметить, что, наверное, одной из причин такого широкого использования является удачное сочетание в этой методике подходов, основанных на использовании явной формулировки принципов Видения общих требований и Концептуальной архитектуры, и достаточно подробные рекомендации как по содержанию документов, так и по организации архитектурного процесса.
При этом применение самой методики для потребностей органов государственного управления и ведомств практически не требует какой-либо специальной ее адаптации.

Оценка зрелости архитектуры государственной организации

Для оценки степени зрелости архитектуры государственных организаций может быть полезна следующая модель GAO (Финансово-контрольное управление США) [9.19], которая определяет 5 уровней зрелости. Рассматриваемый стандарт получил название "Пять стадий зрелости архитектуры Предприятия – GAO's Five Stages of Enterprise Architecture Maturity" и предназначен для использования во всех федеральных правительственных агентствах, департаментах и бюро США.
При этом модель строится по принципу как бы "нарастающего итога", так что каждый последующий уровень по определению включает все "позитивные" характеристики предыдущего. Интересно сравнить описания уровней этой модели с аналогами для коммерческих организаций.
Уровни идентифицируются в соответствии со степенью реализации нескольких основных атрибутов, таких как:

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

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

атрибуты, которые демонстрируют выполнение обязательств, включающие планы и реальные продукты по Архитектуре предприятия;

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

В 2003 году была разработана новая, "более жесткая" версия 1.1 этого стандарта [9.20], которая предъявляет повышенные требования к организации процессов и, соответственно, к достижению того или иного уровня зрелости. Эти дополнительные требования появляются, начиная со стадии 2, и распространяются явно или неявно на последующие стадии. Примерами таких дополнительных требований служит необходимость разработки модели оценки эффективности как для существующего состояния информационных систем, так и для целевого состояния "как должно быть", или явное упоминание необходимости разработки метрик для количественных оценок. На стадии 4 отмечается необходимость проведения независимой оценки предлагаемых архитектурных решений и верификации правильности их реализации.
Рисунок 8.8 показывает распределение государственных ведомств США по различным стадиям зрелости реализованного в них архитектурного процесса, по состоянию на 2003 год. (были проанализированы 96 ведомств). Анализ показал, что многие агентства еще достаточно далеки от желаемого уровня. Фактически уровень 5 достигнут только в Администрации Президента США.

Рис. 8.8.  Сравнительная оценка зрелости корпоративной архитектуры агентств 2003 года
Возникает естественный вопрос: а на каком уровне зрелости архитектуры находятся российские государственные ведомства?

Основные компоненты

Мы уже отмечали, что на региональном уровне и уровне крупных муниципалитетов, как правило, отсутствует необходимость в разработке собственной методологии описания архитектуры. Таким образом, основная проблема состоит не в создании собственной методологии, а в обосновании перед руководством региона или города необходимости практической организации разработки архитектуры и обеспечении долгосрочной поддержки со стороны высшего руководства этих усилий. Ощутимые результаты могут быть получены не сразу, поэтому есть риск угасания интереса к работе, переключения на другие приоритеты и поиск другой "палочки-выручалочки", которая якобы "быстро и безболезненно" решит все проблемы создания, развития и использования информационно-коммуникационных технологий в городе или регионе.
Известные нам практические примеры – описание архитектуры уровня отдельных штатов США, отдельных городов Северной Америки и Европы – основаны на использовании какой-либо одной из известных на практике методологий. При этом нам встречались случаи, когда в основу работ были положены, например, методологии META Group или Gartner.
Спецификой органов государственного управления является то, что они в силу ряда причин должны более явно, четко и структурировано делать достоянием общественности информацию, описывающую практику использования информационных технологий. Это связано как с большей формальной подотчетностью органов власти перед обществом (публичная ответственность государства перед налогоплательщиками) и вышестоящими органами, так и с масштабами, т.е. необходимостью более четко распространять информацию об общей архитектуре, принятых стандартах и правилах достаточно большому количеству людей, рассредоточенных по различным ведомствам. То есть архитектура информационных технологий правительства соответствующего уровня – это механизм распространения информации о соответствующих, связанных с ИТ вопросах внутри ведомств, между ведомствами и с обществом. По крайней мере, так это выглядит в теории, чего нельзя сказать в полной мере об отечественной практике.
В курсе "Архитектура предприятия" в начале лекции, посвященной основным элементам архитектуры предприятия, мы отмечали, что это понятие включает формулировку принципов, целей, задач, стратегий, а также разработку моделей для отдельных доменов архитектуры и, наконец, связанные с ними стандарты, правила и т.д. Мы также приводили примеры архитектурных принципов, которые абсолютно применимы и для органов государственного управления любого уровня.
Остановимся на таких аспектах архитектуры, как цели, задачи и стратегии, и приведем соответствующие примеры. Цели, задачи и обеспечивающие эти задачи стратегии определяются уровнем развития информационных технологий и соответствующими потребностями в них. В качестве примера приведем выдержки с описаниями целей и стратегий Департамента информационных технологий штата Вашингтон, США. [9.18].
В этом документе сформулированы следующие высокоуровневые цели на 2005-2007 года:

максимизировать использование существующей ИТ-инфраструктуры;

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

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

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

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

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

Для достижения этих целей были сформулированы следующие задачи и обеспечивающие решение этих задач стратегии (мы комбинировали для краткости задачи и стратегии на 2003-2005 и 2005-2007 года).

Задача 1: Обеспечить бесперебойную работу основных ИТ-систем

Стратегия 1.1. Обеспечить инвестиции в возможности и устойчивость инфраструктуры.

Стратегия 1.2. Обеспечить защиту критически важных бизнес-функций за счет инвестиции в безопасность сети.

Стратегия 1.3. Инвестировать в средства обеспечения высокой доступности систем и web-технологии.

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

Задача 2: Поддерживать передовые позиции в области электронного правительства через инновации

Стратегия 2.1. Обеспечить эффективность публикации информации на Web с помощью технологий управления контентом.

Стратегия 2.2. Расширить возможности публичного и внутреннего портала.

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

Стратегия 2.4. Обеспечить потребности в области предоставления видео-информации на рабочие места.

Стратегия 2.5. Расширить возможности в области он-лайновых платежей.

Стратегия 2.6. Расширить возможности и использование архитектуры корпоративного (в масштабах всего правительства штата) каталога Active Directory.

Стратегия 2.7. Провести оценку беспроводных и мобильных технологий.

Задача 3: Обеспечить баланс контроля и инноваций в практике управления

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

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

Стратегия 3.3. Обеспечить реализацию основных ИТ-проектов за счет стандартизации процессов управления проектами и обучения.

Стратегия 3.4. Реализовать управление "портфелем портфелей проектов" различных ведомств на основе целостных для всего штата представлений об инвестициях в ИТ.

Задача 4: Стимулировать и обеспечивать межведомственную и межфункциональную кооперацию

Стратегия 4.1. Стимулировать создание и условия использования общей инфраструктуры.

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

Стратегия 4.3. Помогать небольшим по размерам агентствам в использовании общих технологических ресурсов.

Задача 5: Искать дополнительные возможности экономии для пользователей услуг Департамента Информационных Технологий (ДИТ)

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

Стратегия 5.2. Помогать пользователям услуг ДИТ в обмене идеями вместо обмена персоналом.

Стратегия 5.3. Предоставлять своим потребителям и использовать внутри ДИТ лучшие практики в области ИТ-сервисов.

Задача 6: Продолжать использование эффективных и стратегических методов работы внутри ДИТ

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

Стратегия 6.2. Улучшить процессы расчетов за предоставляемые услуги.

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

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

Стратегия 6.5. Использовать проактивные подходы в управлении рисками.

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


Рис. 8.7.  Программа разработки политик, стандартов и процедур

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

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

Примерами руководств служат руководства по управлению проектами, защите частной информации и т.д.

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

Примеры проектов разработки и реализации архитектуры электронного правительства национального уровня

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

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

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

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

Штат Виржиния, США	http://www.cots.state.va.us/ea/eacomp.htm2.2	META Group5.29.3
Штат Северная Каролина, США	http://irm.state.nc.us/	META Group
Штат Коннектикут, США	http://www.ct.gov/doit/cwp/view.asp?A=1245&q=253976&doitnav=1	META Group
Штат Аризона, США	http://gita.state.az.us/enterprise_architecture/	META Group
Штат Мэн, США	http://www.state.me.us/CIO/ITstrat_plan/	Gartner
Штат Кентукки, США	http://enterpriseit.ky.gov/	Методология "4Front" Methodology of Deloitte & Touche Consulting Group
Штат Массачусетс, США	www.state.ma.us/itd/spg/publications/standards/archstan.htm	Нет информации о методике
Штат Огайо, США	http://das.ohio.gov/ITGD/EAHome.htm	Опубликованы отдельные политики в области ИТ
Штат Делавэр, США	www.state.de.us/dti/	Нет информации о методике
Штат Миссури, США	http://oit.mo.gov/e-government/e-government.html	Методика IBM
Штат Небраска, США	http://www.nitc.state.ne.us/	Нет информации о методике
Штат Нью-Йорк, США	http://www.oft.state.ny.us/	Собственная методика, основанная на методиках NASCIO, Gartner Group, META Group
Штат Монтана, США	http://www.discoveringmontana.com/itsd/	Нет информации о методике
Штат Вашингтон, США	http://dis.wa.gov/index.htm	META Group
г. Меса, США (штат Аризона)	http://www.ci.mesa.az.us/isd/strategy.asp	Нет информации о методике
г. Торонто, Канада	http://www.city.toronto.on.ca/city_hall/ecity.htm	Нет информации о методике
г. Оклэнд, США (штат Калифорния)	http://www.oaklandnet.com/government/vision/vision.html	Нет информации о методике
Штат Куинслэнд, Австралия	http://www.iie.qld.gov.au/site/gia/	META Group
Штат Андхра-Прадеш, Индия	http://www.ap-it.com	Price Waterhouse Coopers

В таблице 8. 2 приведены ссылки на сайты с описанием архитектур отдельных государственных ведомств.

Таблица 8.2. Ссылки на сайты с описанием архитектур отдельных государственных ведомствВедомствоСайтИспользованная методология

Департамент энергетики США	http://cio.doe.gov/Publications/publications.html#architecture	Методология Enterprise Architecture Planning (EAP) Спивака
Министерство обороны США	http://www.defenselink.mil/nii/infosuper/Message.html	Методика Министерства обороны DoDAF
Департамент внутренних дел США (функции пожарной службы, охраны природы, охраны национальных меньшинств и т.п.)	http://www.dio.gov/oirm	Federal Enterprise Architecture Framework (FEAF)
Департамент юстиции США	http://www.usdoj.gov/jmd/ocio/ppp.htm	Federal Enterprise Architecture Framework (FEAF)
Федеральное казначейство США	http://www.ustreas.gov/offices/cio/teaf	TEAF, созданная на основе FEAF

Таблица 8.3. Уровни зрелости архитектуры государственной организацииУровеньХарактеристика

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

Стандарты и архитектура прикладных систем электронного правительства (SAGA) Германии

SAGA (Standards and Architecture for e-government Applications) является одновременно и методикой разработки, и описанием реализации электронного правительства Германии (переводится как "Стандарты и архитектура прикладных систем электронного правительства"). В декабре 2003 года была опубликована уже вторая версия этого документа, которая доступна по адресу http://www.kbst.bund.de/saga.
В рамках инициативы BundOnline 2005, реализация которой началась в сентябре 2000 года, Германия планирует к 2005 году реализовать в электронной форме более 400 услуг федерального правительства. Базовыми принципами, декларируемыми в рамках немецкой программы BundOnline 2005, являются следующие: 1) децентрализованная реализация с централизованным мониторингом и обеспечением поддержки, и 2) взгляд на инициативу в целом с точки зрения предоставляемых государством услуг.
Кроме децентрализованного портфеля электронных государственных услуг, которые должны быть реализованы различными ведомствами, план реализации определяет архитектуру электронного правительства, которая, в том числе, включает набор базовых компонент и приложений, разработанных по принципу "один на всех". Для этих базовых компонент мы выше применяли термин "общие сервисы". Базовые компоненты, реализованные в Германии, включают, в том числе, общие портальные сервисы, сервисы управления контентом, сервисы оплаты государственных услуг, сервер электронных форм, компоненты обеспечения безопасности, каталоги.

При этом SAGA носит достаточно прагматичный характер, так что описание архитектуры покрывает только те области, которые оказывают существенное влияние на решение перечисленных задач, т.е. не все элементы технической архитектуры включены в это описание. В дополнение к SAGA как к основному документу, по описанию архитектуры электронного правительства Германии, важную роль играет так называемое "Руководство по электронному правительству" (E-Government Manual), которое доступно на английском языке по адресу http://www.bsi.de/english/index.htm.

Руководство является модульным набором документов, которые покрывают гораздо более широкий спектр проблем, чем в SAGA. В SAGA имеются ссылки на это Руководство, в котором многие темы разбираются более детально и подробно. Имеется также ряд других документов архитектурного характера, например, V-Modell, который описывает процесс разработки прикладных систем; DOMEA (Document Management and Electronic Archiving), который излагает требования к системам работы с электронными документами и файлами, а также системам автоматизации потоков работ (woorkflow) и создания электронных архивов, что очень важно для государственных ведомств.

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

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

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

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

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

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

Важным является оценка прикладных систем на соответствие архитектуре, описанной в SAGA. Прикладная система оценивается на совместимость с архитектурой на основе моделей, процедур и стандартов, описанных в SAGA:

использование стандартных моделей процессов;

использование и учет стандартных моделей данных;

применение стандартов, утвержденных в SAGA, и соответствие архитектуре, описанной в SAGA;

использование разработанных централизованно базовых компонент (общих сервисов).

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

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


Рис. 8.4.  Эталонная модель прикладных систем SAGA

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

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

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

моделирование данных;

архитектура приложений;

клиентская часть;

презентация данных;

коммуникации (протоколы промежуточного слоя, сетевые протоколы, протоколы прикладного уровня, сервисы каталогов);

методы доступа к унаследованным системам;

стандарты в области безопасности данных.

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

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

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

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


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

ИТ - стратегия

Альтернативные взгляды на архитектуру предприятия

Авторы курса искренне верят, что идеи, связанные с разработкой и реализацией архитектуры предприятия, могут принести существенную пользу как в организации работы департаментов информационных технологий, так и в организации их эффективного взаимодействия с бизнес-подразделениями. Однако нам хотелось бы быть до конца честными перед читателями и изложить критические и альтернативные взгляды на теорию и практику Архитектуры предприятия, которые в достаточно сконцентрированном виде были изложены, в частности, в статье [10.1], название которой на русский язык можно перевести как "Архитектура предприятия, покойся с миром!"
Автор статьи утверждает, что архитектура предприятия является ни чем иным, как старой концепцией централизованного планирования "сверху-вниз". Вы начинаете с самого высокоуровнего взгляда на организацию, идентифицируете основные структурные единицы и функции, а затем проводите декомпозицию этих абстрактных представлений со все большей степенью детализации, пока не получаете, в конце концов, работающие системы.
При этом по ходу этого процесса вы специфицируете все необходимые структуры данных и требования по их обработке для всего предприятия в целом, а также стандартизируете требования к аппаратному обеспечению, платформам программного обеспечения и средствам разработки. Когда это сделано, то, по сути дела, вам остается только следовать намеченному пути. То есть, вы создаете всеобъемлющую модель информационных потребностей предприятия и затем работаете в процессе планирования информационных систем этой модели.
Построение такой модели должно начинаться с описания представлений самого высшего руководства о деятельности предприятия. Взгляды других заинтересованных групп людей также должны быть проанализированы. Все это, с точки зрения автора статьи, выливается в грандиозное по своим масштабам обследование, которое принимает форму многодневных сессий стратегического планирования с отрывом от основной работы и большим количеством выпитого за счет организации кофе (как минимум кофе) и съеденных булочек. После того, как с "большими дядями" покончено, наступает очередь других сотрудников, занимающих более низкое положение в иерархии, чьи представления о работе предприятия также должны найти свое отражение. Но все результаты этой работы являются не окончательным продуктом, а основой для другой работы – выработки ИТ-стратегии, планирования и, только потом, исполнения этих планов.
Реальность, в соответствии с такой точкой зрения, такова, что все эти работы вязнут в трясине высокоуровнего планирования на фазе анализа, не принося ничего полезного для организации. То есть, реальность далека от грандиозной теории, поскольку все эти упражнения требуют 18-24 месяцев работы, прежде чем дать хоть какие-то результаты. Представьте себе полтора-два года труда на одной чаше весов и результаты в виде набора моделей, а не работающих систем, на другой чаше весов. И только потом эти модели будут использованы для последующего анализа и, наконец, разработки систем. Будет ли это работать в реальном мире деятельности коммерческих компаний и государственных организаций, находящихся в условиях постоянного дефицита времени и ресурсов?
В соответствии с этой точкой зрения, единственной ценностью и полезным уроком всех этих подходов, что стало понятно еще в начале 1990-х годов, было осознание потребности в некотором уровне планирования и описания данных, используемых организацией.
Что же касается выработки по-настоящему общекорпоративных стандартов, то единственное, что удается и что целесообразно стандартизировать, так это наиболее фундаментальные технологии, такие как сетевые стандарты и конфигурации используемых персональных компьютеров. Попытки стандартизировать что-либо еще являются непроизводительными потерями времени. Программные платформы, средства разработки и даже системы управления базами данных редко удается эффективно стандартизировать в крупной организации. Все равно подразделения найдут способы использовать те технологии, которые, как они считают, лучшим образом отвечают их локальным потребностям. Потребности бизнеса все равно пробьют себе дорогу и будут важнее любых ложных целей типа создания гомогенной среды корпоративных стандартов.
Таким образом, архитектура предприятия и все, что с этим связано – это шаг назад к методам разработки всего и вся "сверху-вниз", в то время как потребности сегодняшнего дня заключаются в быстрых и гибких методах разработки систем. И только они, эти быстрые методы разработки, могут обеспечить действительно эффективные взаимоотношения бизнеса и информационных технологий.
Короче, "Мир праху твоему, архитектура предприятия!".

Объединяем концепции и процессы

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

Рис. 9.1.  Концепции и процессы, связанные с архитектурой
Большинство этих тем нашло отражение в соответствующих лекциях курса.

Заключительные замечания:"Архитектура предприятия мертва! Да здравствует архитектура предприятия!"

Ну что ж. Эта позиция критиков архитектурных подходов понятна, заслуживает внимания, а главное, извлечения положительных уроков. Попробуем это сделать и мы, сославшись на мнение авторитетов [10.2].
Действительно, даже авторы и сторонники архитектурных методик и подходов признают, что достаточно большое количество проектов разработки архитектуры предприятия потерпело неудачу, не добившись быстрой реализации полезных для организации результатов. Но то же самое можно сказать и о многих других подходах к трансформированию бизнеса, включая реинжиниринг бизнес-процессов и внедрение систем управления ресурсами предприятия (ERP-систем).
Авторы критических взглядов на архитектуру предприятия действительно правы в том, что любые инициативы в области организационных изменений – а архитектура предприятия является, по сути, одной из форм структурированных подходов к организационным изменениям, связанным с использованием информационных технологий, – должны приносить определенные положительные результаты не только в отдаленном будущем, но и в краткосрочном плане. В противном случае, они обречены на потерю поддержки руководства, и, как результат, в конечном итоге, от этих работ отказываются.
Однако утверждать, что концепция архитектуры предприятия мертва – это означает одновременно утверждать, что любые шаги по разработке ИТ-стратегии и планированию информационных технологий (в основе чего и лежит архитектура предприятия) вообще не имеют смысла. В конечном итоге, такой подход сулит ИТ-анархию внутри организаций – и это в условиях, когда мир вокруг нас все больше думает об экономии ресурсов при постоянно растущем количестве взаимосвязей между системами, росте требований со стороны государства и высшего руководства организаций по предоставлению своевременной информации, росте угроз и проблем в области информационной безопасности.
Следует помнить о том, что архитектура предприятия – это одновременно и результат, и процесс достижения этого результата. Это процесс обеспечения синхронизации потребностей и возможностей бизнеса и информационных технологий. Это процесс декомпозиции и трансформации, как правило, достаточно нечетко обозначенных стратегий и потребностей бизнеса в имеющие смысл и хорошо формализованные требования, предъявляемые к системам, процессам, информации и инфраструктуре. Очень часто Архитектура предприятия выражается в создании набора моделей и диаграмм. При этом все мы знаем, что одна картинка, один рисунок стоит тысячи слов. А в отношении модели можно сказать, что одна модель стоит миллиона слов!
Мы уже говорили, что в основе концепций Архитектуры предприятия лежат работы Захмана, которые, в свою очередь, основаны на методиках IBM-планирования бизнес-систем (BSP – Business System Planning), разработанных в 70-х годах прошлого века. Они создавались для того, чтобы обеспечить механизмы оптимального инвестирования в ИТ-системы и разрабатывать оптимальные стратегии сопровождения и эксплуатации систем. Эти методики, в том числе, помогали организациям формализовывать и стандартизировать процессы еще до этапа их автоматизации. Мы все знаем, что когда автоматизированы плохие процессы, порядок вещей становится только хуже: все будет работать так же плохо, но только с большей скоростью и с еще большим отрицательным эффектом.
До начала 1990-х годов в своем первозданном виде Архитектура предприятия была адекватным подходом. Однако по мере того как развивалось программное обеспечение, по мере того как коммерческое программное обеспечение становилось независимой отраслью деятельности, аппаратное обеспечение также начинало становиться все более стандартным. На смену философии "никто никогда не был уволен за то, что он покупает IBM" пришла философия "программное обеспечение определяет выбор платформы".Эта смена философии привела к смене подходов по разработке Архитектуры предприятия. Разработка моделей данных в виде диаграмм "сущность-связи" в нормальных формах для всей информации, которую предприятие будет использовать в будущем, перестало быть адекватным подходом. Почему? В 1990-х годах появились корпоративные программные продукты, каждый со своими моделями данных: например, системы управления ресурсами предприятия (ERP), системы управления поставками (SCM), системы управления отношениями с заказчиками (CRM). Все, кто добровольно отказался в этих условиях от планирования через разработку Архитектуры предприятия, в полной мере испытали проблемы одновременного использования нескольких корпоративных систем внутри предприятия, имеющих перекрывающийся функционал и пересекающиеся наборы данных.
Если уж Архитектура предприятия не является универсальной палочкой-выручалочкой, то же самое мы можем сказать по отношению к коммерчески доступным корпоративным системам масштаба предприятия, особенно о тех, которые внедряются в отсутствии процессов планирования и управления. Сегодня уже не редкость встретить организации, в которых используется несколько корпоративных систем управления ресурсами предприятия. Насколько в этих условиях к ним применимо определение "корпоративные"?
Мы уже говорили, ссылаясь на данные аналитических компаний, таких как META Group, что организации, которые используют стандарты в рамках единой Архитектуры предприятия, нередко достигают 30% экономии затрат на реализацию своих ИТ-систем.
Сейчас мы вступаем (или уже вступили) в новый, после эпохи Web, этап создания информационных систем, характеризующийся взаимопроникновением коммуникаций и обработки данных, когда следующей наиболее существенной концепцией является сервис-ориентированная архитектура (SOA), которую мы кратко рассмотрели в лекции 4. В условиях отсутствия нормальных процессов планирования и проектирования систем в масштабе всей организации в целом, насколько эффективным будет "открытие" функционала наших прикладных систем для заказчиков и партнеров через сеть (что лежит в основе принципов SOA)?
Архитектура предприятия как процесс нужна более, чем когда-либо ранее. Она необходима для рационализации и исключения избыточных прикладных систем, которые имеются в организации. Она необходима для обеспечения минимально достаточного уровня процессов проектирования, контроля и управления цифровым хаосом, который присутствует во многих организациях.
Недаром федеральное правительство США требует от федеральных ведомств разработки своих собственных архитектур в рамках общих концепций Федеральной Архитектуры. Это делается, в частности, для того, чтобы обеспечить большую совместимость между системами отдельных ведомств, исключить неэффективные затраты. Опыт учит, что проведение предварительного анализа является основой для лучшего проектирования систем и позитивных изменений в процессах и используемых данных.
При этом Сервис-ориентированная архитектура, в основе которой лежит философия совместимости, взаимодействия и повторного использования функционала систем, в существенной степени основана на принципах Архитектуры предприятия. Причина в том, что Архитектура предприятия помогает не только в плане идентификации стандартов на форматы данных, протоколы, но также в определении, какая часть прикладных систем должна быть реализована в виде самостоятельных сервисов и как эти сервисы могут быть скомбинированы вместе для того, чтобы составить эффективно работающую прикладную систему. Архитектура предприятия также нужна, чтобы определить все необходимые метаданные, которые требуются для реализации эффективной сервис-ориентированной архитектуры, включая web-сервисы.
Конечно, теоретические представления и практика Архитектуры предприятия претерпели существенные изменения в течение последних лет. Изменились приоритеты и подходы. Сегодня уделяется меньше внимания вопросам стандартизации аппаратного обеспечения (скорее, это уже считается само собой разумеющимся). Специалисты в большей степени фокусируются на рационализации и стандартизации других активов (бизнес-процессов, прикладных систем, данных) так, чтобы сделать их доступными более широкой аудитории пользователей и удовлетворяющими, в том числе, регулирующим требованиям государства.
Эти отличия между "старыми" и "новыми" представлениями об архитектуре приведены в таблице 9.1 ниже [10.3].

Таблица 9.1. Атрибуты "старой" и "новой" архитектуры"Старая" архитектура ИТ"Новая" архитектура предприятия

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

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

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

Так что, "Архитектура предприятия мертва! Да здравствует Архитектура предприятия!"

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



    Работа с информацией: Cистемы - Технологии - Рынок

• Анализ информационных систем
  
• Методы информационных систем
  
• Интернет как информационная система
  
• Искусственный интеллект в информационных системах
  
• Обработка информации информационными системами
  
  
• Информационные системы в офисе
  
• Управление информационными системами
  
• Технологии информационных систем
  
• Теория информационных систем
  
• Почта - информационная система
  
  
• Outlook и информационные системы
  
  
• Информационный рынок
  
• Информационный рынок - IT
  
• Технологии информационного рынка
  
• Безопасность на информационном рынке