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

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

 

Модели бизнес-архитектуры бывают различных типов:

· модели процессов/потоков работ,

· функциональные модели,

· организационные модели,

· модели данных/ресурсов,

· временные модели типа диаграмм Ганта,

· модели причинно-следственных связей.

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

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

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

Шаг 1. Идентификация критически важных для предприятия процессов (обычно не более восьми).

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

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

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

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

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

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

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

Шаг 5. Идентифицировать и документировать основные категории информационных объектов (опять же рекомендуется не более восьми).

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

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

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

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

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

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

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

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

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

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

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

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

 

Таблица 2.2. Компоненты декомпозиции функций/процессов

 

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

 

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

 

Таблица 2.3. Компоненты анализа бизнес-событий

 

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

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

Таблица 2.4. Компоненты модели местоположений

 

Основная область анализа	Результаты (артефакты) анализа	Основные вопросы
· Обеспечить понимание того, где выполняются функции и процессы · Понимание требований, накладываемых географическим расположением на решения, касающиеся бизнес- и технологической архитектуры · Понимание требований со стороны технологической архитектуры к географическому расположению функций	· Распределение функций по местоположениям · Связи между бизнес-функциями · Требования к технологической архитектуре и архитектуре прикладных систем · Возможности по организационным изменениям	· Где выполняются основные функции? · Какие функции связаны между собой? · Существуют ли возможности по консолидации и рационализации?

 

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

 

Таблица 2.5. Компоненты модели интеграции

 

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

 

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

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

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

· Анализ пересечений и непокрытых областей (Gap-overlap analysis) (Будет ли наша бизнес-архитектура иметь избыточные элементы, и есть ли в ней "пробелы"?)

· Соотнесение затрат с активностями (Activity-based costing) (На каких процессах, каналах продаж и заказчиках мы реально зарабатываем или теряем деньги?)

· Обучение (Как эти бизнес-процессы соотносятся с другими?)

· Общая стоимость владения (Сколько стоит этот процесс?)

· Возврат инвестиций (ROI) (Будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?)

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