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

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

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

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

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

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

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

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

В основе архитектуры предприятия заложен «Архитектурный взгляд» на системы, определенный в стандарте ANSI/IEEE 1471, как «фундаментальная организация системы, состоящая из совокупности компонент, их связей между собой и внешней средой, и принципы, которыми руководствуются при их создании и развитии».

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

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

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

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

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

При этом архитектура предприятия неразрывно связана с основными рабочими процессами:

· стратегия и планирование на уровне предприятия;

· управление корпоративными проектами.

Рисунок 1.1. Взаимосвязь бизнеса и ИТ

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

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

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

Рисунок 1.2. Управление портфелем ИТ.

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

· максимизация ценности портфеля;

· синхронизация ИТ - портфеля с требованиями бизнеса;

· поиск оптимального баланса между риском и потенциальной отдачей от ИТ - портфеля.

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

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

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

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

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

Уровень отдельных решений – определяет структуру и функции в рамках отдельных проектах. На этом уровне, формируется детализированная информация о приложениях, бизнес-процессах и их взаимосвязях. Здесь определяется структура информационных систем, их интерфейсы и функции. Определяются планы и схемы их развития, разрабатывается соглашение об уровне обслуживания (SLA).

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

Рисунок 1.3. Контекст и уровни абстракции архитектуры предприятия.

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

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

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

· Уровень контекста (почему?) ориентирован в первую очередь на руководство и обосновывает необходимость проектов.

· Концептуальный уровень (что?) определяет общие требования к проекту и возможные варианты его реализации.

· Логический уровень (как?) описывает способ реализации данного проекта.

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

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

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

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

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

Рисунок 1.4. Эволюция организационных принципов.

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

Текущая архитектура (Current architecture) - описывает существующее состояние архитектуры предприятия. Называется также архитектурой “как есть” (AS-IS) или базовым состоянием существующей архитектуры.

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

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

Процесс разработки текущей архитектуры аналогичен процессу ITIL/ITSM(управление конфигурацией - Configuration Management). Для упрощения работы по разработке текущей архитектуры многие компании используют базу данных конфигурационных единиц (CMDB), дополнив ее необходимой информацией.

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

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

· стратегические требования к бизнес-процессам и информационным технологиям;

· информация о выявленных «узких местах» и путях их устранения;

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

Целевая архитектура (модель to-be) и текущая архитектура (модельas-is) позволяют описать начальное и конечное состояние предприятия – до и после внесения изменений в его структуру, оставляя без внимания сам процесс изменений.

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

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

Рисунок 1.5. Основные слои архитектуры предприятия

· Стратегические цели и задачи предприятия.

· Бизнес – архитектура предприятия.

· Архитектура информационных технологий (ИТ архитектура предприятия).

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

· Информационную архитектуру (Enterprise Information Architecture).

· Архитектуру прикладных решений (Enterprise Solution Architecture).

Виктор Галактионов, 20.05.2002
Журнал "Директор ИС", #05, 2002 год // Издательство "Открытые Системы" (http://www.osp.ru/)

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

Я — географ, а не путешественник. Мне ужасно не хватает путешественников. Ведь не географы ведут счет городам, рекам, горам, морям, океанам и пустыням. Географ — слишком важное лицо, ему некогда разгуливать. Он не выходит из своего кабинета. Но он принимает у себя путешественников и записывает их рассказы.

Антуан де Сент-Экзюпери. «Маленький принц». Глава 15. Географ

Известно, что бизнес любой современной компании все больше и больше становится зависим от информационных технологий. Развитие отдельных направлений бизнеса, например развитие «карточного бизнеса» в банках, стало возможным исключительно благодаря появлению современных ИТ. Конечно, это справедливо и для предприятий других отраслей. Потому можно надеяться, что излагаемый опыт без значительных усилий по адаптации может быть использован в бизнесе любой другой, небанковской компании.
Особенности сегодняшнего уровня развития банковских информационных технологий заключается в том, что во многих банках, которые смогли сохранить свой бизнес после кризиса 1998 года и сегодня продолжают его активно развивать и наращивать, высокотехнологичные банковские решения внедряются на фоне продолжающейся эксплуатации программных систем и комплексов предыдущих поколений, зачастую морально устаревших. С другой стороны, остановка банковского бизнеса даже на несколько часов, тем более остановка на один или несколько дней для вывода из эксплуатации устаревшего программного обеспечения и ввода в эксплуатацию нового, в большинстве случаев будет равносильна утрате бизнеса. В этой ситуации в каждый момент времени необходимо иметь четкое представление о текущем статусе всех внедряемых и эксплуатируемых информационных систем, а также не менее четкое понимание их дальнейшего развития с учетом перспектив развития банка, его архитектуры как архитектуры предприятия . (В англоязычной литературе — методиках, статьях, стандартах — этому соответствует термин enterprise architecture .)
Следует отметить, что архитектура предприятия существует независимо как от нашего сознания, так и от размера этого предприятия — будь то глобальная корпорация, небольшой завод, малое торговое предприятие и т. п. У малого предприятия архитектура есть так же, как и у крупного, при этом они не слишком сильно различаются по составу компонентов. Однако одни руководители это понимают и могут себе позволить уделять внимание всем аспектам устройства своего же предприятия (это, как правило, руководители крупных компаний), а другие — нет. Иное дело, что у малого предприятия могут быть всего два-три продукта, миссия и стратегия в явной форме не зафиксированы (эта беда, кстати, встречается часто и в крупных компаниях), количество сотрудников составляет 30 человек и в производстве используется два компьютера с MS Word 97. Но и в таком случае это все и составляет архитектуру данного предприятия.
В статье представлен достаточно развернутый и одновременно прагматичный подход к организации работ по анализу архитектуры предприятия в целом и планированию системной архитектуры, в том числе к ее документированию. Основными целями документирования знаний о бизнесе (разработки архитектуры предприятия) являются обеспечение сохранности инвестиций в бизнес и прозрачности бизнеса на всех уровнях.
Прозрачность бизнеса начинается с прозрачности понимания архитектуры предприятия, с четкого разделения ее на три взаимозависимых уровня: стратегический уровень, уровень бизнес-архитектуры, уровень системной архитектуры. Системная архитектура определяется бизнес-архитектурой, и ее проектирование может осуществляться только на основании бизнес-архитектуры, которая в свою очередь зависит от стратегии предприятия. Этот подход позволяет, на наш взгляд, не только правильно организовать сами работы и произвести корректное разделение функций и ответственности бизнес-архитектора («бизнес-девелопера»), отвечающего за развитие бизнеса, то есть бизнес-архитектуры предприятия, и системного архитектора, но и, самое главное, выстраивать сбалансированную архитектуру предприятия, адекватно соответствующую его миссии и стратегии.
В начале статьи приведены основные определения. Затем рассмотрен состав и содержание системной архитектуры, проанализированы взаимосвязи сущностей бизнес-архитектуры и системной архитектуры. Достаточно детально рассмотрены фазы и участники жизненного цикла системной архитектуры, в частности функции участников. Наконец, в сокращенном виде представлена структура знаний, лежащих в основе системной архитектуры, и сделаны заключительные выводы.

Базовые понятия

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

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

Рассматриваемая в статике архитектура предприятия состоит из следующих элементов:

• миссия и стратегия, стратегические цели и задачи;
• бизнес-архитектура;
• системная архитектура.

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

Рис. 2.

Таким образом, архитектура предприятия в общем случае описывается следующими последовательно зависимыми разделами (см. рис. 1 и рис. 2):

• сформулированные миссия и стратегия банка, стратегические цели и задачи;
• бизнес-архитектура в текущем (as is) и планируемом (to be) состоянии,
• системная архитектура в текущем (as is) и планируемом (to be) состоянии;
• планы мероприятий и проектов по переходу из текущего состояния в планируемое.

На рис. 1 показано, что выполнение плана миграции не означает замораживания развития бизнес- и системной архитектуры. Таким образом, планируемая системная архитектура является архитектурой «to be» только на определенном витке развития предприятия. Одновременно возврат к стратегическому уровню миссии и стратегических целей и задач не означает необходимость пересмотра миссии и стратегии. Но в конце каждого цикла обязательно проводится анализ эффективности разработанных и осуществленных мероприятий, при необходимости при второй итерации корректируются бизнес-архитектура, системная архитектура, реализуются новые планы миграции. В каждый момент времени может быть несколько циклов, каждый такой цикл не обязательно затрагивает все предприятие в целом, цикл может затрагивать отдельные направления, отдельные вопросы бизнеса и может быть зафиксирован в виде отдельного проекта.
При поэтапном плане миграции для фиксации достигнутых результатов возможно построение промежуточных (миграционных) одной или нескольких архитектур.
Миссия, стратегия и бизнес-цели определяют направления развития банка и ставят долгосрочные цели и задачи.
Бизнес-архитектура на основании миссии, стратегии развития и долгосрочных бизнес-целей определяет необходимые организационную структуру, структуру каналов продаж и функциональную модель банка, документы, используемые в процессе разработки и реализации продуктов. Функциональная модель описывает бизнес-процессы, направленные на реализацию текущих задач и перспективных целей.
Бизнес-архитектура включает в себя:

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

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

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

Системная архитектура

Системная архитектура состоит из трех взаимосвязанных компонентов — прикладной архитектуры, архитектуры данных и технической архитектуры (см. рис. 3). Системная архитектура в системе стандартов данного предприятия определяет правила формирования своих компонентов и обеспечения взаимодействия между ними.

Рис. 3.

Компоненты системной архитектуры

Прикладная архитектура включает в себя:

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

Архитектура данных включает в себя:

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

Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ.
Сетевая архитектура включает в себя:

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

Архитектура платформ включает в себя:

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

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

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

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

Взаимосвязи системной архитектуры и бизнес-архитектуры

Архитектура предприятия полностью описывается следующими сущностями (см. рис. 4):

1. Миссия и стратегия банка, стратегические цели и задачи.
2. Продукты и бизнес-процессы.
3. Документы.
4. Организационная структура.
5. Приложения.
6. Данные.
7. Оборудование.
8. Планы мероприятий и проектов по переходу из текущего состояния в планируемое.

Рис. 4. Взаимосвязь сущностей верхнего уровня архитектуры предприятия

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

Рис. 5. Архитектура предприятия и место в ней системной архитектуры

На рис. 5 дано укрупненное графическое отображение архитектуры предприятия и определяющих ее компонентов.
Пример ключевых взаимосвязей между основными элементами бизнес-архитектуры и системной архитектуры показан на рис. 6 в форме ER-диаграммы.

Рис. 6.

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

Жизненный цикл системной архитектуры

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

Рис. 7.

Жизненный цикл системной архитектуры состоит из следующих фаз: (см. рис. 7):

• начальное документирование;
• использование;
• проектирование;
• миграция.

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

Рис. 8.

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

• анализ осуществимости;
• разработка технического задания;
• разработка технического проекта;
• разработка и документирование ПС;
• тестирование ПС;
• внедрение ПС;
• эксплуатация ПС;
• вывод ПС из эксплуатации.

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

Начальное документирование

Фазе жизненного цикла системной архитектуры «Начальное документирование» нет прямого соответствия в фазах ЖЦ программных средств. Содержательно эта фаза представлена функциями ее активных участников (см. табл. 1).

Таблица 1.

Использование

Фазе жизненного цикла системной архитектуры «Использование» соответствуют следующие фазы ЖЦ программных средств:

• Разработка технического задания на ПС.
• Разработка технического проекта ПС.
• Тестирование ПС.

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

Таблица 2.

Проектирование

Здесь может возникнуть вопрос: а куда делась разработка постановки задачи? И нужна ли она вообще? Фазе жизненного цикла системной архитектуры «Проектирование» соответствуют следующие фазы ЖЦ программных средств:

• Подготовка технического задания на ПС.
• Подготовка технического проекта ПС.

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

1. изменениями миссии или стратегии;
2. изменениями рыночной ситуации;
3. регулирующими органами.

После осознания этой потребности производится формулирование бизнес-требований, но все это происходит, когда мы еще находимся в слое бизнес-архитектуры (см. рис. 4). Стрелки от сущностей «Продукты» и «Документы», направленные к сущностям «Оборудование», «Программы» и «Данные», соответствуют постановке задачи (бизнес-требованиям). Вернемся к нашему примеру, из которого мы видим, что разработка ТЗ, ТП, тестирование и внедрение хранилища данных используют знания о системной архитектуре системы бухгалтерского учета, которая уже находится в промышленной эксплуатации, а ее системная архитектура в настоящий момент находится в фазе использования. Системная же архитектура хранилища данных в настоящий момент находится в фазе проектирования (см. рис. 8).
Функции активных участников фазы «Проектирование» представлены в табл. 3 .

Таблица 3.

Миграция

Фазе жизненного цикла системной архитектуры «Миграция» соответствуют следующие фазы ЖЦ программных средств:

• Тестирование программных средств.
• Внедрение программных средств.

Функции активных участников фазы «Миграция» представлены в табл. 4 .

Таблица 4.

Таким образом, системная архитектура реально затрагивается на следующих фазах ЖЦ программных средств:

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

Состав базы знаний по системной архитектуре

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

1. Текущая системная архитектура.
2. Перспективная (планируемая) системная архитектура.
3. Планы миграции.

Разделы «Текущая системная архитектура» и «Перспективная системная архитектура» имеют одинаковую структуру и состоят из следующих подразделов:

1. Принципы построения системной архитектуры.
2. Основные технические и технологические решения.
3. Требования и стандарты.
4. Прикладная архитектура.
5. Техническая архитектура.
6. Архитектура данных.

Принципы построения

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

Основные решения

Описываются главные технические и технологические решения, составляющие основу системной архитектуры. Например, это может быть решение об использовании ЭВМ AS/400 в качестве основной аппаратной платформы информационной системы банка или решение об использовании СУБД DB2 в качестве основного инструмента управления информационными ресурсами банка.
Каждое решение снабжается комментарием, поясняющим, каким образом данное решение соответствует сформулированным выше принципам построения системной архитектуры.
Главные решения, принимаемые в ходе проектирования системной архитектуры, оформляются отдельными документами, с кратким изложением предыстории, сути проблемы и принятого принципиального решения проблемы, обязательного в последующем при проектировании, разработке и внедрении информационной системы.

Требования и стандарты

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

Прикладная архитектура

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

Техническая архитектура

Сетевая архитектура

Содержит описания территориальной коммуникационной инфраструктуры и локальных вычислительных сетей (ЛВС).

Архитектура платформ

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

Архитектура данных

Базы и хранилища данных

Содержит описание баз данных и иным способом организованных информационных массивов.

Системы управления базами данных

Содержит описание используемых систем управления базами данных.

План миграции

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

Заключение

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

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

Конечно, возникает также множество других вопросов, так или иначе связанных с системной и бизнес-архитектурой.
В силу ограниченного размера журнальной статьи разбор этих вопросов выходит за ее пределы. Отметим только, что для структуризации и документирования этих знаний возможностями программ MS Word или MS Excel не обойтись. Необходимо использование более развитых программных комплексов, но еще важнее использование соответствующих методик или даже методологий. Одним из таких руководств, которое, по опыту автора, удовлетворяет нужным требованиям, является «методология ARIS» (ARchitecture of Integrated Information System). Однако это совершенно другая тема, возможно, для другой статьи.

1. Архитектурное описание предприятия: как сделать видимой организацию работ

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

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

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

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

Архитектор -- это тот, кто придумывает такую архитектуру, которая удовлетворит все заинтересованные стороны. Эту архитектуру он придумывает, описывает в виде Архимейт-диаграмм, и согласовывает её с разными важными людьми. Сам момент описания архитектуры на Архимейте неважен. Те, кто просто пишут на Архимейте (испанском, суахили) под диктовку, не могут называться архитекторами, они просто писари (писцы). Ну ладно, архиписари (архиписцы).

Для многих людей, назначенных архитекторами, оказывается полной неожиданностью неминуемый переход от изображения на Архимейте результатов разных интервью в качестве "архитектурного описания as is" к сочинению "архитектурного описания to be" и немедленно следующему плотному общению с начальством по поводу превращения свежесочиненных диаграмм Архимейта в организационную реальность предприятия. Архимейт поможет вам в вашем деле не больше, чем спеллчекер Ворда в получении нобелевской премии по литературе.

Вы предупреждены.

2. Люди, программы, оборудование

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

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

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

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

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

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

Если вы собираетесь как-то менять архитектуру предприятия в реальной жизни (а иначе зачем вы вообще стали рисовать диаграммы Архимейта?), то для этого можно использовать ещё:
-- 7 типов элементов для целеполагания и обоснования изменений в организации
-- 4 типа элементов для проектирования перехода к новой архитектуре

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

Вот и весь Архимейт. Но не нужно обольщаться его простотой. В Великом и Могучем тоже всего 33 буквы.

4. Нужен не ты, нужен твой сервис.

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

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

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

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

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

5. Люди

Напомним пункт три: для описания уровня организации работы людей Архимейт имеет столько же типов элементов (17), сколько для уровней программ и оборудования вместе взятых (7+9) -- и это совсем не случайно.

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

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

6. Роли

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

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

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

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

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

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

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

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

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

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

7. Работы людей

Работы людей бывают такие:

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


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

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

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

* * *

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

Кому и зачем нужна «Архитектура предприятия»?

Copyright © 2009 Забегалин Е.В.

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

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

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

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

«Enterprise Architecture», по-русски «Архитектура предприятия» (АП), сложилась в общую дисциплину как ступень исторического развития множества методологий, относящихся к архитектуре автоматизированных информационных систем - это методологии Дж. Захмана, Ст. Спивака, CIMOSA, GERAM, TOGAF и др. Анализ этого исторического процесса достаточно содержательно представлен в .

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

The Zachman Framework for Enterprise Architecture ;

стандарт ISO 19439:2006 «Enterprise integration - Framework for enterprise modelling»;

стандарт ISO 15704:2000. Industrial automation systems - Requirements for enterprise-reference architectures and methodologies;

«Federal Enterprise Architecture» (FEA), практикуемая и развиваемая правительством США ;

«Extended Enterprise Architecture Framework» (E2AF), развиваемая независимой организацией «Institute For Enterprise Architecture Developments» ;

The Open Group Architecture Framework (TOGAF) .

Наряду с этим в России в 2000 году была разработана и опубликована концептуальная архитектурная схема «3D-Предприятия», в которой матричные идеи Дж. Захмана были дополнены третьим – временным – измерением для отражения трансформации структуры предприятия .

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

Рисунок 1 - У руководителей и аналитиков есть практическая необходимость всегда иметь достаточно содержательные знания об устройстве организации (предприятия)

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

В интересах практического приложения дисциплины АП преодоление указанной искусственности может быть начато с поиска ответа на вопрос: кому и зачем на предприятии может быть нужна «Архитектура предприятия»?

2 Назначение «Архитектуры предприятия»

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

Этот вывод следует из того, что все указанные на схеме объекты менеджмента являются одновременно объектами для отражения в модели АП, которая в будущем станет также объектом менеджмента (архитектурная модель предприятия показана на схеме как его компонент).

Рисунок 2 - Обобщенная структура предприятия

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

Рисунок 3 - «Архитектура предприятия» может быть использована для поддержки основных функций менеджмента

Из роли АП, как инструмента менеджмента, могут быть выведены, по меньшей мере, две основные функции «Архитектуры предприятия»:

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

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

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

Рисунок 4 - Основные функции «Архитектуры предприятия»

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

"Zachman Framework for Enterprise Architecture", "Extended Enterprise Architecture Framework", "TOGAF",

"GERAM", стандартом ISO 19439-2006 (уровни "Generic", "Partial", "Particular").

После Дж. Захмана наиболее конкретно и последовательно управленческие уровни использования АП предложены в схеме «3D-Предприятия» - «Главные потребности, цели, планы, ограничения», «Бизнес-модель», «Логическая модель», «Техническая архитектура», «Детальная реализация», «Практика использования» .

3 Состав «Архитектуры предприятия»

Все архитектурные методологии сходятся в том, что для достаточно содержательного описания устройства предприятия (организации) необходимо использовать множество различных точек зрения (views) на это устройство. Эти точки зрения могут называться также архитектурными доменами, содержательными аспектами и т.п. Описание (и моделирование) структуры предприятия во множестве различных точек зрения и дает в итоге «Архитектуру предприятия».

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

в Zachman Framework for Enterprise Architecture - это "Data", "Function", "Network", "People", "Time", "Motivation";

в Extended Enterprise Architecture Framework (E2AF) - это "Business", "Information", "Information

Systems", "Technology Infrastructure";

в GERAM и в ISO 19439-2006 - это "Function", "Information", "Resource", "Organization";

в TOGAF - это "Business", "Information", "Application", "Technology".

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

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

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

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

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

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

В «Матрице Захмана» этот аспект обозначается наименованием первой строки "Scope" ("The purpose of the Row 1 are to define the boundaries of the Enterprise, what is being included …" ).

В Federal Enterprise Architecture (FEA) - это "Performance Reference Model".

В E2AF и в GERAM логический аспект в явном виде не выделен и включен в аспект "Business". Однако в основных принципах E2AF утверждается: "No strategy, no enterprise architecture ... No Scope - No enterprise architecture

The Scope and the Goals & Objectives sets the level of abstraction of the enterprise architecture ... Business Drivers, Goals & Objectives are leading ..." .

В TOGAF логическому аспекту соответствует "Architecture Vision" ("... key elements of the "Architecture Vision" - ...

enterprise mission, vision, strategy, and goals ..., include architecture principles, define breadth of coverage of enterprise, the specific architecture domains …" ).

Подводя итог обзору логического аспекта и пользуясь философским языком, можно утверждать необходимость логического аспекта структуры предприятия для представления "Интегральной идеи предприятия", "Интегрального замысла предприятия", "Интегрального понятия предприятия", по-английски можно предложить - "The Notion of the Enterprise".

4) Хронологический аспект - предприятие создается, функционирует и изменяется с течением времени. Прошедшие, текущее и планируемые структурные состояния предприятия должны фиксироваться, т. е. - это «История жизни».

В GERAM, в ISO 15704-2000, ISO 19439-2006 для структурирования временного аспекта предложено множество стадий жизненного цикла: "Identification", "Concept", "Requirements", "Design", "Implementation", "Operation", "Decommission".

В методологии TOGAF - Architecture Development Method (ADM) - временной аспект отражается последовательностью стадий разработки, внедрения и изменения самой «Архитектуры предприятия».

Схема «3D-Предприятия» позволяет во временном измерении АП планировать перспективные состояния предприятия, включая отдельные проекты и программы развития. В частности последовательность реализации технологических компонентов (систем) предприятия может предусматривать: стратегический анализ целей и потребностей, конструирование технических решений, детальную реализацию системы решений, внедрение решений, использование (эксплуатацию) системы, совершенствование системы .

Рисунок 5 - Основные точки зрения на структуру предприятия

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

Компонентами строительной архитектуры предприятия могут рассматриваться:

организационная архитектура - это организационная структура предприятия;

имущественная архитектура - это структура собственности предприятия;

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

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

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

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

структура бизнес-функций и бизнес-процессов предприятия;

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

Рисунок 6 - Комплексное представление «Архитектуры предприятия»

Помимо четырех основных видов архитектуры предприятия возможны и другие, соответствующие другим точкам зрения, например:

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

Бизнес-архитектура - это архитектура предприятия, рассматриваемая без его ИТ-архитектуры.

4 Как получить и использовать «Архитектуру предприятия»

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

Первый путь потребует от менеджмента предприятия:

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

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

самостоятельной разработки и документирования методического обеспечения АП;

самостоятельной разработки АП.

Разработка АП внешними консультантами потребует от менеджмента предприятия заключения контракта на выполнение работ:

по непосредственной разработке АП;

по разработке и документированию методического обеспечения АП;

по созданию архитектурной службы предприятия.

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

удобный и не требующий лицензирования доступ менеджеров и специалистов предприятия к электронной модели АП.

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

Список использованных источников

1. Зиндер Е. «3D-предприятие» – модель стратегии трансформирующейся системы. «Директор информационной службы», №4, 2000. http://www.sept2000.ru/articles/2008/03/03/1/ .

2. Зиндер Е. Архитектура предприятия в контексте бизнес-реинжиниринга. «Intelligent Enterprise/Корпоративные системы», №4, №7, 2008.

3. Галактионов В. Системная архитектура и ее место в архитектуре предприятия. «Директор информационной службы», №5, 2002.

4. Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия. М. Интернет-Университет Информационных технологий, 2005.

5. Дрожжинов В., Штрик А. Стандартизация архитектуры государственных ведомств США. PC Week/RE. №28, №31, 2005.

6. Zachman John A. The Zachman Framework. http://www.zachmaninternational.com/

7. The Office of Management and Budget. Federal Enterprise Architecture (FEA). http://www.whitehouse.gov/omb/e-gov/fea/

8. Schekkerman J. Extended Enterprise Architecture Framework Essentials Guide. Institute For Enterprise Architecture Developments, 2006. http://www.enterprise-architecture.info/

9. The Open Group Architecture Framework (TOGAF). http://www.opengroup.org/architecture/togaf8doc/arch/toc.html

10. Generalized Enterprise Reference Architecture and Methodology (GERAM). IFIP–IFAC, 1999.

11. Иванова И.А. Менеджмент: Учебное пособие. - М.: Издательство РИОР, 2004.

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

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

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

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

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

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

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

Зачастую стандартные ответы на эти вопросы связаны с упором на оптимизацию бизнес-процессов организации и, соответственно, перечислением «базового набора» параметров оптимизации:

♦ дублирование функций;

♦ узкие места;

♦ затратные центры;

♦ качество выполнения отдельных операций;

♦ избыточные операции;

♦ возможности автоматизации;

♦ возможности внедрения систем управления качеством;

♦ возможности сертификации по ISO 900х.

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

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

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

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

♦ формализация и документирование информации (знаний) об организации.

Очевидно, что вне зависимости от целей оптимизации качественное накопление, структурирование и формализация информации (знаний) очень важны с точки зрения:

♦ технологической поддержки процессов сохранения ноу-хау организации;

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

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

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

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

♦ задачи;

♦ показатели эффективности;

♦ регламенты (инструкции, приказы и т. п.) бизнес-процессов.

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

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

♦ систематизация и документирование (формализация) информации (знаний), значимой для деятельности, что обеспечивает:

а) технологическую основу для внутрикорпоративного сохранения и доступности специализированных знаний (ноу-хау) организации;

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

Рис. 1. Проблематика управления знаниями в организации в части бизнес-процессов

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

Рис. 2. Перспективные решения по использованию знаний о бизнес-процессах при принятии управленческих решений

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

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

а) ISO 15704 – стандарт по формальному описанию архитектуры предприятия, который был предложен рабочей группой IFAC/IFIP (International Federation of Automatic Control/International Federation for Information Processing);

б) ISO 15288 – стандарт, определяющий жизненный цикл системы;

в) ISO 12207 – стандарт, определяющий жизненный цикл программного обеспечения.

Существует более 30 дополнительных «поддерживающих» стандартов системной и программной инженерии (например, ISO 14258, определяющий концепции и правила моделирования предприятия).

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

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

Постановки задач по моделированию бизнес-архитектуры в контексте поддержки SOA направлены на обеспечение следующих требований проектирования ИС:

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

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

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

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

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

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

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

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

В подтверждение данных тезисов в отношении роли и места бизнес-моделирования можно привести высказывание аналитика Gartner Джима Синура (Jim Sinur): «На самом деле большинство предприятий в действительности не понимают всей глубины и масштабов выполняемых ими бизнес-процессов, если они не занимались бизнес-моделированием в последнее время» . В целом необходимо отметить, что по различным экспертным оценкам большинство предприятий будут вести проекты, которые так или иначе будут затрагивать различные аспекты проблемы совершенствования бизнес-процессов, несмотря на неоднозначные оценки практики реинжиниринга бизнес-процессов середины 1990-х годов.

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

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

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

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

Очевидно, что постановки задач по моделированию для производственной (коммерческой) организации существенно могут отличаться от задач государственного контрольного (надзорного) органа. По этой причине, безусловно, необходима специфическая настройка каждой из методик высокого уровня под область моделирования. На эту потребность вполне адекватно реагирует рынок консалтинговых услуг. Так, в настоящее время есть практически значимые модели для различных отраслей экономики и госструктур, которые реализованы на основе разных методологий и инструментальных средств моделирования, таких как методология ARIS и базирующееся на ней семейство программных продуктов компании IDS Sheer AG, язык моделирования UML и средство разработки объектно-ориентированных информационных систем Rational Rose компании IBM, методология IDEF, DFD и продукт AllFusion Modeling Suite (ранее BPwin и ERwin) компании Computer Associates и др.

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

Следует отметить, что ОГВ РФ, отвечающие за формирование научно-технической политики в различных областях, проведение административных реформ, довольно «чутко» отнеслись к вышеперечисленным мировым тенденциям и определили целевые задачи по их учету в РФ.

Состояние формализации и на ее основе оптимизации административно– управленческих процессов ОГВ определено в документе «Стратегия развития и использования информационных и коммуникационных технологий в Российской Федерации» в качестве основных показателей планируемых мероприятий. Приведенная ниже таблица отражает текущее состояние, перспективы и государственную политику по внедрению бизнес-моделирования в деятельность ОГВ РФ (табл. 1).

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

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

♦ внедряются электронные административные регламенты;

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

♦ оптимизируется организационная структура.

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

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

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

При этом пользователями модели бизнес-архитектуры предприятия в рамках подразделений может выступить достаточно обширная аудитория специалистов и руководителей:

♦ бизнес-аналитики по различным направлениям предметной (целевой) деятельности организации;

♦ разработчики информационных и технологических систем;

♦ системные архитекторы, которые отвечают за создание архитектуры отдельных информационных систем;

♦ бизнес-аналитики, которые ведут процесс проектирования организационной структуры;

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

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

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

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

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

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

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

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

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

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

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

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

1) систематизация и формализация – построение описательных моделей;

2) построение аналитических и оптимизационных моделей.

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

1) качественно-количественная оценка (оптимизация) реализуемых бизнес-процессов;

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

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

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

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

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

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

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

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

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

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

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

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

♦ определение этапности;

♦ определение ролей в проекте;

♦ формирование и управление в проектной команде и т. д.

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

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

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

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

Усилия по построению бизнес-архитектуры, которая представляется в виде бизнес-моделей, быстро окупают себя и имеют большое количество дополнительных преимуществ . Преимущества от построения модели бизнес-архитектуры моделей лежат в двух плоскостях: дополнительных возможностях для бизнеса и уменьшении затрат. По оценкам, создание бизнес-моделей и связанная с этим оптимизация затрат даже без радикальных изменений бизнеса могут дать до 10 % экономии. А при моделировании альтернативных вариантов бизнес-процессов организации могут сэкономить до 20 % .