Архитектура предприятия.

 

Лекция 7.

 

Тема лекции: «Бизнес-архитектура».

1.      Контекст и основные элементы бизнес-архитектуры.

2.      Основные модели и инструменты описания бизнес-архитектуры.

3.    Сервис-ориентированная архитектура (SOA) и архитектура, управляемая моделями (MDA).

1. КОНТЕКСТ И ОСНОВНЫЕ ЭЛЕМЕНТЫ БИЗНЕС-АРХИТЕКТУРЫ.

 

1.1.               Понятие бизнес-архитектуры.

 

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

 

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

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

 

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

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

Для систематизации элементов АП воспользуемся подходом Акоффа Р. и Эмери Ф. (см.: Акофф Р., Эмери Ф. О целеустремленных системах. – М: Советское радио, 1974.) к анализу и описанию целеустремленных систем (какой является и предприятие).

 

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

 

1. Структура, 2. Функция и 3. Цель.

 

Таким образом, при рассмотрении предприятия будем использовать «системный треугольник» — предприятие как система должно быть описано с трех сторон:

1. С точки зрения ее предназначения, замысла, целей и т. д.;

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

3. С точки зрения организации этой деятельности — здесь «цементируются» первые два взгляда в некоторой структуре организации (конструкции).

 

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

 

1.2.               Стратегическая карта (или карта стратегий) и система сбалансированных показателей.

1.2.

Сбалансированная система показателей (см.: Каплан Р., Нортон Д. Сбалансированная система показателей. От стратегии к действию. – М.: Олимп-Бизнес, 2003.) (Balanced Scorecard) разработана на основе выводов исследования, проведенного в начале 1990-х годов профессором Harvard Business School Робертом Капланом (Dr. Robert S. Kaplan) и президентом консалтинговой фирмы Renaissance Solutions Дэвидом Нортоном (David P. Norton). Исследование проводилось с единственной целью: выявить новые способы повышения эффективности деятельности и достижения целей бизнеса. Суть этой системы коротко формулируется двумя основными положениями:

 

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

 

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

Стратегическая карта (см.: Каплан Р., Нортон Д. Стратегические карты. Трансформация нематериальны  активов в материальные результаты. – М.: Олимп-Бизнес, 2004.)

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

 

ФИНАНСОВАЯ СОСТАВЛЯЮЩАЯ описывает материальные результаты реализации стратегии при помощи традиционных финансовых понятий. Такие показатели, как ROI, стоимость для акционеров, прибыльность, рост доходов и удельные издержки, являются отсроченными индикаторами, свидетельствующими об успехе или провале стратегии компании.

 

КЛИЕНТСКАЯ СОСТАВЛЯЮЩАЯ определяет предложение потребительной ценности для целевых клиентов.

 

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

Как организация достигает запланированных результатов?

 

СОСТАВЛЯЮЩАЯ ВНУТРЕННИХ ПРОЦЕССОВ, ИЛИ ВНУТРЕННЯЯ СОСТАВЛЯЮЩАЯ, определяет несколько важнейших процессов, которые имеют решающее значение в реализации стратегии. Например, одна организация может увеличить инвестиции в разработку и продвижение на рынок новых продуктов и технологию их производства таким образом, что в результате клиенты получат высокотехнологичный инновационный продукт. Другая, пытаясь предоставить аналогичное предложение потребительной ценности, принимает решение создавать новые товары, используя совместные предприятия и партнерства.

СОСТАВЛЯЮЩАЯ ОБУЧЕНИЯ И РАЗВИТИЯ отражает те нематериальные активы, которые являются наиболее важными для стратегии. Цели этой составляющей устанавливают виды деятельности (человеческий капитал), системы (информационный капитал) и моральный климат (организационный капитал), необходимые для поддержки процессов создания стоимости. Все они должны быть взаимосвязаны и соответствовать основным внутренним процессам.

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

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

СТРАТЕГИЧЕСКАЯ КАРТА описывает логику стратегии, четко показывая важнейшие внутренние процессы, которые создают стоимость, и определяя нематериальные активы, необходимые для их поддержки.

СБАЛАНСИРОВАННАЯ СИСТЕМА ПОКАЗАТЕЛЕЙ переводит цели стратегической карты в показатели и конкретные задачи. Но цели и задачи нельзя достичь, только определив их, — организация должна запустить целый комплекс программ, с помощью которых будут получены все намеченные показатели. Для каждой такой программы компания обязана предоставить достаточные ресурсы — людей, финансирование, мощности. Авторы подхода называют эти программы стратегическими инициативами. Для каждого показателя сбалансированной системы менеджеры должны определить стратегические инициативы, необходимые для достижения целей. Инициативы порождают результат.

Следовательно, реализация стратегии достигается через реализацию инициатив.

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

Каждое стратегическое направление отражает конкретную деловую ситуацию.

В итоге ССП предлагает системный подход к определению целей и показателей, которые описывают стратегию.

 

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

 

1.3.               Модель мотивации бизнеса BMM (Business Motivation Model).

1.3.

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

С какой целью разрабатывается модель BMM?

 

Как следует из документа «Business Motivation Model, Version 1.0», эта модель с организационной точки зрения определяет схему или структуру разработки, взаимодействия и управления бизнес-планами предприятия. В соответствии с BMM, предприятия не могут и не должны действовать случайным образом. Термин «мотивация» означает, что, если предприятие собирается использовать определенный подход к своей деятельности, выраженный в ее миссии, стратегии и тактике, то модель BMM должна дать возможность обосновать (мотивировать) этот подход и помочь определить, какой результат может быть достигнут.

 

BMM реализована в ряде программных продуктов для управления АП.

Краеугольные камни мотивации бизнеса — Видение и Миссия.

Видение воплощается в Целях и Задачах, а Миссия — в Стратегиях достижения Целей и Тактиках выполнения Задач.

 

Обобщающий термин «Краевое условие» (Ends) относится к Видению, Целям и Задачам. Обобщающий термин «Средства» (Means) относится к Миссии, Стратегии и Тактике. Краевое условие связано с Желаемым результатом, а имеющиеся Средства используются для формирования Курса действий.

Концепция модели мотивации бизнеса BMM состоит в установлении связей между Краевым условием (к чему предприятие стремится) и Средствами (что предприятие собирается предпринять).

На практике приходится учитывать многочисленные внутренние и внешние Источники влияния, которые могут, как способствовать, так и препятствовать деятельности предприятия. Необходимо задуматься об использовании своей силы (Strengths) и о компенсации своей слабости (Weaknesses), научиться использовать возможности (Opportunities) и реагировать на угрозы (Threats). Модель BMM предусматривает обязательную Оценку потенциального влияния различных источников. После Оценки влияния Источников на Краевое условие и Средства, в рассмотрение должны быть добавлены Директивы, определяющие Курс действий. Директивы нужны, чтобы удержать предприятие в рамках выбранного Курса и направить его в сторону достижения Желаемых результатов. Из-за существенного влияния на Курс действий Директивы вместе с Миссией и Курсом действий включены в состав Средств.

В состав Директив входят Бизнес-политика и Бизнес-правила.

Бизнес-политика — менее формализованный и структурированный документ, чем Бизнес-правила. В модели BMM так обосновывается необходимость этих документов:

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

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

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

 

В качестве других стандартов предложены стандарты OMG: метамодель для организационной структуры (OSM, Organization Structure Metamodel), метамодель для бизнес-процессов (BPDM, Business Process Definition Metamodel) и спецификация бизнес-правил (SBVR, Semantics of Business Vocabulary and Business Rules).

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

 

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

 

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

 

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

 

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

 

1. БИЗНЕС-СТРАТЕГИЯ, функции и организационные структуры – собрание целевых установок, планов и структур организации. Данная информация может быть представлена в самых разных форматах, но наиболее важный аспект состоит в создании контекста для описания бизнес-процессов. Эта часть архитектуры не является технической, но она критически важна с той точки зрения, что архитектура информационных технологий (информации, прикладных систем, технологическая архитектура) строится на ее основе и обеспечивает реализацию ключевых функций организации.
2. АРХИТЕКТУРА БИЗНЕС-ПРОЦЕССОВ, которая определяет основные функциональные области организации. Для министерства – это могут быть функции, перечисленные в Положении о министерстве, для коммерческой организации – процессы разработки новых продуктов, услуг и сбыта товаров и т.п. Она также описывает специфические процессы внутри каждой функциональной области и их операционные параметры – например, объемы операций, роли, реализацию централизованной или децентрализованной модели операций и т.д. Эта часть является как бы «точкой соприкосновения» между бизнес-архитектурой и архитектурой приложений и обеспечивает взгляд на бизнес и функции организации, достаточно детализированный для того, чтобы использовать его при выработке стратегии и планов создания приложений.
3. ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ. Этот аспект состоит в определении ключевых показателей эффективности (КПЭ) работы организации, их текущих уровней и желаемых, будущих уровней и включает в себя также разработку на верхнем уровне модели КПЭ для мониторинга.

 

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

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

1)   Каков внешний контекст деятельности организации?

2)   В чем состоят основные функции и добавочная стоимость, которая является итогом деятельности организации?

3)   Какие сценарии развития бизнеса необходимо учитывать, и какова вероятность их реализации?

4)   Какие необходимы информационные взаимосвязи и процессы обработки информации?

Рисунок 1. Контекст Бизнес-архитектуры.

 

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

 

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

 

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

 

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

 

Далее рекомендуется выполнить следующие шаги.

 

Шаг 1. ИДЕНТИФИКАЦИЯ КРИТИЧЕСКИ ВАЖНЫХ ДЛЯ ПРЕДПРИЯТИЯ ПРОЦЕССОВ (обычно не более восьми).

 

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

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

- процессы, которые в настоящее время выполняются плохо и являются источниками неудовлетворенности клиентов;

- процессы, в которых имеются возможности для экономии.

 

Желательно, чтобы рекомендуемое число таких процессов, не превышало «волшебного числа» 8 в соответствии с известным принципом: «семь плюс-минус два» объекта. При необходимости схожие бизнес-процессы могут быть объединены в группы или классы.

 

Шаг 2. ОТСЛЕДИТЬ СВЯЗИ МЕЖДУ ЭТИМИ ПРОЦЕССАМИ И БИЗНЕС-СТРАТЕГИЯМИ, ДВИЖУЩИМИ СИЛАМИ И КРИТИЧЕСКИ ВАЖНЫМИ ФАКТОРАМИ УСПЕХА. Это можно сделать с помощью матрицы взаимных связей. Для каждого элемента этой матрицы определяется качественная оценка по принципу «важно» – «неважно» или по некоторой условной шкале. Например, можно использовать так называемую шкалу 9-3-1, в соответствии с которой 9 обозначает сильную взаимосвязь, 3 – промежуточную, 1 – слабую.

 

Шаг 3. ПОСТРОИТЬ МОДЕЛИ ВЫСОКОГО УРОВНЯ ДЛЯ КЛЮЧЕВЫХ БИЗНЕС-ПРОЦЕССОВ. Это включает последовательность основных шагов (желательно, не более восьми на процесс).

 

Шаг 4. ДЛЯ КАЖДОГО ШАГА ПРОЦЕССОВ, ИДЕНТИФИЦИРОВАННЫХ НА ЭТАПЕ 3, ОПРЕДЕЛИТЬ ОТВЕТСТВЕННЫХ ЗА ВЫПОЛНЕНИЕ ШАГА. Это может быть функциональное подразделение внутри организации, партнер, клиент, внешний регулирующий орган.

 

Шаг 5. ИДЕНТИФИЦИРОВАТЬ И ДОКУМЕНТИРОВАТЬ ОСНОВНЫЕ КАТЕГОРИИ ИНФОРМАЦИОННЫХ ОБЪЕКТОВ (опять же рекомендуется не более восьми).

 

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

 

 

2. ОСНОВНЫЕ МОДЕЛИ И ИНСТРУМЕНТЫ ОПИСАНИЯ БИЗНЕС-АРХИТЕКТУРЫ.

 

2.1. Бизнес-модели как способ формализации бизнес-стратегии.

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

 

Одним из распространенных методов представления бизнес-моделей является предложенный Александром Остервальдером. Популярность и широкое распространение метод получил после публикации в 2010 году книги «Построение бизнес-моделей» (Business Model Generation). За несколько лет книга была переведена на 18 языков и продана в количестве более 500 000 экземпляров.

БИЗНЕС-МОДЕЛЬ — ЭТО ПРЕДСТАВЛЕНИЕ БИЗНЕС-СИСТЕМЫ В ВИДЕ СОВОКУПНОСТИ 9 СТРУКТУРНЫХ БЛОКОВ, ИМЕЮЩИХ КЛЮЧЕВОЕ ЗНАЧЕНИЕ ДЛЯ БИЗНЕСА:

 

Элементы бизнес-модели.

1)   Потребительские сегменты (кто является потребителями, на кого ориентирован бизнес?)

1)

2)   Ценностное предложение (что уникального мы предоставляем нашим клиентам, каковы наши отличительные особенности?)

2)

3)   Каналы сбыта (каким образом мы доставляем наше предложение клиентам?)

3)

4)   Взаимоотношения с клиентами (как мы осуществляем коммуникации с клиентами и поддержку?)

 

5)   Потоки поступления доходов (какие основные каналы поступления доходов?)

5)

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

6)

7)   Ключевые виды деятельности (какая деятельность является ключевой для того чтобы все остальное работало?)

7)

8)    Ключевые партнеры (кто является ключевыми партнерами?)

8)

9)   Структура издержек (на что направлены основные издержки?)

9)

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

ПРИМЕР.

В 2001 году Apple запустила свой легендарный бренд: портативный медиаплеер iPod. Устройство работает с программным обеспечением iTunes, которое позволяет переносить музыкальные файлы и другую информацию с iPod на компьютер. Программное обеспечение также поддерживает постоянную связь с онлайн-магазином Apple, что позволяет приобретать интересующий пользователей контент.

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

Каким образом Apple удалось выйти в лидеры? Она использовала лучшую бизнес-модель. С одной стороны, компания предложила пользователям возможность наслаждаться музыкой без каких-либо проблем, объединив в одном предложении уникальное по дизайну устройство iPod, программное обеспечение iTunes и доступ к онлайн-магазину. Это ценностное предложение позволяло легко отыскивать, приобретать и прослушивать музыку. С другой стороны, чтобы сделать ценностное предложение реально возможным, Apple пришлось заключить соглашения со всеми звукозаписывающими компаниями для создания крупнейшей в мире музыкальной онлайн-библиотеки.

Итог? Большую часть своих «околомузыкальных» доходов Apple получает от продажи iPod, а интеграция с музыкальным онлайн-магазином позволяет ей обходить конкурентов.

Бизнес-модель бизнес-направления iPod компании Apple представлена на рис. 2.11.

 

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

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

Автор предлагает метод управления на основе бизнес-модели, включающий следующие шаги: мобилизация (вовлечение сотрудников); понимание (освоение методов и подходов); дизайн (создание бизнес-модели «as is», анализ, проектирование «to be»); применение (проверка прототипа «to be» в реальных условиях); управление (адаптация и постоянное совершенствование модели на основе реакции рынка).

Существуют приложения (в том числе и на планшетные ПК) для создания бизнес-моделей. Например, приложение «Strategyzer» позволяет не только создавать и редактировать модели, но и производить первичные расчеты (получается упрощенный аналог бизнес-плана).

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

 

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

 

2.2. Бизнес-процессы.

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

1)   Процесс — устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя /клиента (ИСО 9000:2000).

1)

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

2)

3)   Бизнес-процесс — структурированный набор действий, охватывающий различные сущности предприятия и подчиненный определенной цели (ISO/CD 15531-1).

3)

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

Процессный подход позволил выделить процессы как объект управления, что легло в основу дисциплины «управление бизнес-процессами» (Business Process Management, BPM), в основе которой, в свою очередь, лежит цикл Деминга-Шухарда и идея непрерывного совершенствования.

 

ЭТАПЫ ЦИКЛА:

 

- Планирование (Plan): установление целей и процессов, необходимых для достижения целей, планирование работ и распределение необходимых ресурсов.

- Выполнение (Do): выполнение запланированных работ.

- Проверка (Check): сбор информации и контроль результата, выявление и анализ отклонений, установление причин отклонений.

-  Воздействие, закрепление результата (Act): принятие мер по устранению причин отклонений от запланированного результата, изменения в планировании и распределении ресурсов.

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

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

 

Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architeсt, BPWin (новое название – AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно. В данном курсе мы не будем останавливаться на сравнительном анализе этих и других средств, и отсылаем читателя к специализированным публикациям.

 

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

 

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

- декомпозиция функций/процессов;

- анализ бизнес-событий;

- моделирование местоположений выполнения функций/процессов;

- модель интеграции функций/процессов.

ДЕКОМПОЗИЦИЯ БИЗНЕС-ПРОЦЕССОВ состоит в идентификации подпроцессов, которые составляют основу выполнения бизнес-функций, определении границ основных организационных единиц и определении вклада каждой функции в цепочку создания добавочной стоимости.

 

Декомпозиция функций/процессов должна:

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

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

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

- идентифицировать пересечения и излишние функции/процессы.

 

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

 

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

 

МОДЕЛЬ МЕСТОПОЛОЖЕНИЙ идентифицирует в географическом плане то место, где выполняются функции бизнеса, и обеспечивает логистический взгляд на функции, выполняемые организацией. Одним из очевидных преимуществ использования этой модели является идентификация архитектурных требований, которые предъявляются, в частности, к технологической архитектуре с точки зрения обеспечения информационного взаимодействия между различными местами расположения бизнеса. Однако целью моделирования местоположений является визуализация организационных единиц, определение мест, где выполняются функции и связей между ними.

 

МОДЕЛЬ ИНТЕГРАЦИИ отражает высокоуровневые требования к интерфейсам между процессами и бизнес-событиями, требования, предъявляемые к информации новыми шаблонами процессов, и временные требования. Эта модель служит основой для построения архитектуры информации и архитектуры прикладных систем, а также содержит общие требования к архитектуре предприятия с точки зрения бизнес-информации и интеграции.

 

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

 

1. Анализ цепочек создания добавочной стоимости (А нужно ли вообще выполнять этот шаг?)
2. Динамическое моделирование (Как эта модель выполнения бизнес-функций будет себя вести при различных значениях на входе и доступных ресурсах, и как со временем будет меняться поведение процесса?)
3. Анализ пересечений и непокрытых областей (Gap-overlap analysis) (Будет ли наша бизнес-архитектура иметь избыточные элементы, и есть ли в ней «пробелы»?)
4. Соотнесение затрат с активностями (Activity-based costing) (На каких процессах, каналах продаж и заказчиках мы реально зарабатываем или теряем деньги?)
5. Обучение (Как эти бизнес-процессы соотносятся с другими?)
6. Общая стоимость владения (Сколько стоит этот процесс?)
7. Возврат инвестиций (ROI) (Будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?)

 

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

 

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

 

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

 

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

 

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

 

В связи с развитием принципов сервис-ориентированной архитектуры SOA и появлением технологически нейтрального, платформенно-независимого языка описания и выполнения бизнес-процессов BPEL (Business Process Execution Language) появилась возможность не только моделировать бизнес-процессы, но и делать их целиком или частично доступными другим системам и организациям в виде сервисов. К этому можно добавить также возможности еще одного стандарта XML Metadata Interchange (XMI) для обмена (экспорта/импорта) данных практически в любые интеграционные продукты. В совокупности это дает возможность создавать модели и репозитории бизнес-процессов для их эффективной интеграции. (Более подробную информацию о новых стандартах для моделирования процессов можно найти).

 

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

 

2.3. Проекты.

 

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

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

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

Другое определение гласит:

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

Успешному решению всех этих задач способствует то, что «управление проектами» — достаточно хорошо проработанная и стандартизированная область менеджмента. Наиболее известные стандарты управления проектами — это разработанный PMI (Project Management Institute)  стандарт PMBOK (Project Management Body of Knowledge) и, разработанный на его основе, стандарт ISO 10006:1997.

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

2.4. Кейсы и управление ими.

 

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

 

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

 

В настоящее время работа с кейсами идет в рамках направления «адаптивное управление кейсами» (ACM, Adaptive Case Management).

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

Сейчас говорят все чаще не просто case management, а adaptive case management — адаптивное управление кейсами. «Адаптивный» — это не просто планирование в фиксированной структуре, а адаптация к изменению структуры: включение по ходу дела новых участников работ, новых видов работ, новых маршрутов прохождения работ и т. д., планирование кейсов в ходе исполнения (run-time, а не design-time).

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

 

Можно предложить еще одно сравнение — правила получения звуков на музыкальных инструментах при коллективной игре в «традиционном симфоническом оркестре» и в джазовом ансамбле. Важно, что в джазе импровизируют не совсем на 100%: есть четкое понимание стиля, и есть джазовые стандарты. Это повторяет и адаптивное управление кейсами: про деятельность по разрешению кейса кое-что известно в design-time, например, какие-то паттерны/шаблоны из предыдущего опыта работы с подобными кейсами — это просто то, что известно про кейсы из прошлого опыта, в том числе и те работы, которые с ними проводятся. Также в управлении кейсом используются библиотеки правил — движение адаптивного-управления кейсами считает себя наследником движения экспертных систем.

2.5. Бизнес-правила.

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

1)     Бизнес-правила — набор условий, которые управляют деловым событием, чтобы оно происходило так, как нужно для предприятия (или клиента).

1)

2)      Бизнес-правила — это положения, определяющие или ограничивающие какие-либо стороны бизнеса. Их назначение — защитить структуру бизнеса, контролировать или влиять на его операции.

2)

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

1. Бизнес-пользователи (предоставить им формализованный подход управления бизнес-правилами);
3. ИТ-специалисты (предоставить им понимание бизнес-правил и инструментов их моделирования).

Примерами бизнес-правил являются:

«Доставка заказа оплачивается клиентом»,

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

«Если заказанный товар отсутствует на складе, то заказ передается в производственный отдел»,

«Если оплата по счету не поступила в течение 15 дней, заказ считается отмененным»,

«Если сумма заказа составляет от 100 руб. до 200 руб., скидка составляет 10%».

 

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

 

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

Для программного исполнения бизнес-правил используются специальные системы управления бизнес-правилами (англ. Business Rule Engine).

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

2.6. Бизнес-способности (business capability)

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

Способности компании — это элемент ресурсного подхода (resource-based view), популярного в современном стратегическом менеджменте. Данный подход направлен на изучение источников устойчивых конкурентных и сформировался в конце 1980-х годов 84 .

Акцент в нем сделан не на рынке продуктов, а на рынке ресурсов фирмы. Была высказана мысль о том, что все фирмы неоднородны по своим ресурсам, следовательно, при выборе конкурентной стратегии нужно исходить из конкретных ресурсов фирмы. Кроме того, только редкие и ценные ресурсы, которые не могут быть воспроизведены конкурентами, можно использовать для получения прибыли выше средней в длительном периоде. Для более точного описания ресурсов, которые могут стать источником конкурентных преимуществ, была разработана концепция ценного, редкого, неимитируемого и незаменимого — в английской аббревиатуре VRIN (valuable, rare, inimitable,on-substitutable) — ресурса. Таким может быть практически любой ресурс компании: технология, работники, местоположение и т. п.

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

 

2.7.               Бизнес-шаблоны.

 

Большой интерес при создании бизнес-архитектуры предприятия представляют бизнес-шаблоны. В соответствии с  описание бизнес-шаблона включает:

1)   описание поддерживаемой бизнес-функции;

2)   данные, которые требуются для выполнения описанной бизнес-функции;

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

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

 

В качестве другого примера рассмотрим возможности предложенных компанией IBM «шаблонов для электронного бизнеса».

 

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

 

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

 

При этом:

 

- бизнес-шаблоны (Business pattern) предназначены для описания взаимодействия между участниками процесса;

 

- шаблоны дизайна (Design pattern) отражают внутреннюю компонентную структуру системы;

 

- шаблоны уровня приложений (Application pattern) определяют различные варианты взаимодействия между пользователями, приложениями и данными в системе, а также соответствующий прототип уровня выполнения;

 

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

В соответствии с предлагаемой схемой выделяются 4 основных бизнес-шаблона (рисунок 2).

 

 

Рисунок 2. Модель шаблонов электронного бизнеса IBM.

 

ИНТЕГРИРОВАННЫЙ ДОСТУП          

 

Cамообслуживание (U2B- User-to-Business)      

 

Cотрудничество (U2U – User-to-User)

 

Агрегированная информация (U2D – User-to-Data)

 

Расширенное предприятие (B2B- Business-to-Business)

ИНТЕГРАЦИЯ ПРИЛОЖЕНИЙ

 

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

 

Эти шаблоны предназначены для описания таких типовых областей, как:

 

1)   интерактивная – взаимодействие пользователя с предприятием (например, продажа товаров и услуг не по каталогам) – U2B;

2)   программное взаимодействие между приложениями различных предприятий (B2B);

3)   коллективная работа пользователей, включая электронную почту, обмен мгновенными сообщениями, общие форумы и т.п. – U2U;

4)   поиск информации в каталогах и базах данных, анализ данных, подписки – U2D;

5)   взаимодействие между приложениями «в рамках предприятия», в том числе и не обязательно с использованием web-интерфейсов;

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

7)   обеспечение безопасности.

 

Шаблоны могут быть использованы по отдельности или в комбинации при реализации более сложных комплексных решений. Для идентификации классов этих решений общеупотребительным стали аббревиатуры, использующие сходное звучание в английском языке цифры 2 и отношения между двумя сторонами – системы типа B2B, B2C и т.д. Например, традиционный электронный магазин (B2C) может включать элементы прототипов U2D (User-to-Data – работа пользователя с каталогом товаров), U2B (User-to-Business – оформление заказа), U2U (User-to-User – консультация у продавца или обращение в службу поддержки).

 

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

 

Прежде всего, стоит выделить две категории, связанные с уровнем реализации взаимодействия,

 

– интеграция на уровне процессов и интеграция на уровне данных.

 

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

 

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

 

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

 

Примерами таких общих служб могут являться:

 

- преобразование данных (в частности, объединение/разделение, подстановки, округления, перевод c языка на язык, использование XSL для преобразования XML->XML и т п);

 

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

 

- гарантированная доставка;

 

- репозиторий сообщений и метаданных;

 

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

 

- планирование задач и активностей;

 

- журналирование и аудит;

 

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

 

- управление системами, в том числе обнаружение ошибок, мониторинг параметров;

 

- служба каталогов;

 

- безопасность, включая шифрование данных.

 

Аналогичные архитектурные шаблоны в терминологии Microsoft представляют собой Решения уровня предприятия. Они группируются в виде специальной модели в соответствии с уровнем абстракции и архитектурным доменом (рисунок 3).

 

 

Рисунок 3. Категоризация архитектурных шаблонов Microsoft.

 

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

 

3. СЕРВИС-ОРИЕНТИРОВАННАЯ АРХИТЕКТУРА (SOA) И АРХИТЕКТУРА, УПРАВЛЯЕМАЯ МОДЕЛЯМИ (MDA).

 

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

 

Речь идет, прежде всего, о сервисной модели взаимодействия между приложениями общей системы в рамках так называемой сервис-ориентированной архитектуры (Service-oriented architecture SOA) и о реализации архитектуры, «управляемой моделями» (модельная архитектура. Model-driven architecture MDA).

 

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

 

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

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

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

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

 

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

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

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

 

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

 

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

 

В частности, одним из важных результатов стала разработка специализированного языка BPEL (Business Process Executable Language for Web Services) для описания аспектов взаимодействия различных сервисов с точки зрения реализации бизнес-правил. Вообще говоря, принятие SOA как целевой архитектуры будет подразумевать и соответствующий подход к разработке приложений (SODA – service-oriented development architecture).

 

Для задач электронного бизнеса соответствующая функциональность SOA реализуется на уровне web-сервисов (служб). Под web-сервисами понимаются программные системы, которые используют XML в качестве формата данных, стандарты Web Services Description Language (WSDL) для описания своих интерфейсов, Simple Object Access Protocol (SOAP) для описания формата принимаемых и посылаемых сообщений и стандарт Universal Description, Discovery and Integration (UDDI) для создания каталогов доступных сервисов. И хотя принципы сервис-ориентированной архитектуры создания информационных систем не обязательно предполагают использование технологий web-сервисов, связь между этими двумя направлениями в развитии информационных технологий является достаточно тесной. При этом web-сервисы являются технологическими спецификациями, в то время как сервис-ориентированная архитектура (SOA) является принципом проектирования архитектуры программных систем.

 

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

 

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

 

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

 

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

 

Эта модель состоит из следующих основных компонент:

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

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

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

4)   cервисы уровня данных реализуют средства извлечения и повторного использования данных из СУБД и приложений. Явное выделение такого уровня позволяет изолировать вышестоящие компоненты архитектуры от изменений в технологиях (например, смены вендора или версии продукта), а также обеспечить единый  унифицированный подход к выполнению операций с данными;

5)   уровень инфраструктуры, приложений и СУБД является как бы основой для всей структуры, и именно здесь концентрируются основные инвестиции в ИТ.

 

 

 

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

 

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

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

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

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

-Уже существующие приложения можно многократно использовать с помощью адаптеров.

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

 

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

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

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

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

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

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

 

MDA ЯВЛЯЕТСЯ ЕЩЕ ОДНОЙ ВАЖНОЙ АРХИТЕКТУРНОЙ КОНЦЕПЦИЕЙ СОЗДАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ.

 

Концепция MDA была предложена консорциумом OMG (Object Management Group, http://www.omg.org/), в который сегодня входит более 800 известных производителей программного и аппаратного обеспечения. MDA является определенным обобщением идей SOA, с одной стороны, и повторно используемых программных компонент (шаблонов, паттернов) с другой, предназначенным, прежде всего, для повышения гибкости разрабатываемых приложений масштаба предприятия, чтобы обеспечить простоту обеспечения соответствия требованиям бизнеса в условиях изменения используемых инфраструктурных платформ.

 

MDA по определению является открытой и «нейтральной» по отношению к используемым технологиям интеграции. Она основана на следующих принципах:

1)   основой для разработки приложений масштаба предприятия являются детальные модели с общепринятой нотацией;

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

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

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

 

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

 

 

Рисунок 4. Создание прикладных систем в соответствии с подходом MDA.

 

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

 

Более подробная информация по MDA доступна на сайте http://www.omg.org/mda, а также на сайтах практически всех ведущих производителей систем моделирования и разработки приложений.

 

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

 

 

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.

 

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

 

[2] Калянов Г. Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. Учебник для вузов. 2-е изд., доп. – Горячая линия-Телеком М., 2014. –  210 с. 

[3] Кудрявцев Д.В., Арзуманян М.Ю.,  Григорьев Л.Ю. Технологии бизнес-инжиниринга.  Учебное  пособие / под редакцией Д.В. Кудрявцева. — СПб.:  Изд-во Политехн. ун-та, 2014.

 

[4] Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: РИА «Стандарты и качество», 2004 – 408 с. (Серия «Практический менеджмент»).

 

[5] Трутнев Д.Р.  Архитектуры информационных систем. Основы проектирования: Учебное пособие. – СПб.: НИУ ИТМО (Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики), 2012. – 66 с.