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

Рис. 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) (Будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?)

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