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

Бизнес-архитектура

Большинство организаций имеют достаточно широкие определения того, что
является бизнес-архитектурой и бизнес-моделями. Бизнес-архитектура является областью, которая определяется высшими руководителями, отвечающими за основные функции организации. Как правило, она включает в себя утверждения по поводу миссии и целей организации, критические факторы успеха, бизнес-стратегии, описания функций, а также структуры и процессы, необходимые для реализации функций.
По оценке Gartner, вплоть до конца 2008 года около 70% всех предприятий вели определенные проекты, связанные с анализом и совершенствованием бизнес-процессов. «На самом деле, большинство предприятий в действительности не понимают всей глубины и масштабов выполняемых ими бизнес-процессов, если они не занимались бизнес-моделированием в последнее время», – считает Джим Синур (Jim Sinur), аналитик Gartner.
Ключом к построению бизнес-архитектуры является определение бизнес-процессов, их функций и характеристик. Это становится основой для построения архитектуры приложений, которые обеспечивают эти процессы. Таким образом, можно сказать, что Бизнес-архитектура включает в себя, как правило, следующие аспекты:

• Бизнес-стратегия, функции и организационные структуры – собрание целевых

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

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

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

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

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

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

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

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

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

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

Желательно, чтобы рекомендуемое число таких процессов, не превышало 8-ми
в соответствии с известным принципом: «семь плюс-минус два» объекта. При необходимости схожие бизнес-процессы могут быть объединены в группы или классы.
Шаг 2. Отследить связи между этими процессами и бизнес-стратегиями, движу-
щими силами и критически важными факторами успеха. Это можно сделать с помощью матрицы взаимных связей. Для каждого элемента этой матрицы определяется качественная оценка по принципу «важно» – «неважно» или по некоторой условной шкале.
Шаг 3. Построить модели высокого уровня для ключевых бизнес-процессов. Это включает последовательность основных шагов.
Шаг 4. Для каждого шага процессов, идентифицированных на этапе 3, опреде-
лить ответственных за выполнение шага. Это может быть функциональное подразделение внутри организации, партнер, клиент, внешний регулирующий орган.
Шаг 5. Идентифицировать и документировать основные категории информационных объектов. Такое небольшое количество высокоуровневых моделей и понимание их связей с ключевыми факторами и факторами успеха позволяет понять в целом деятельность организации и использование ИТ-ресуров. Более детальные модели полезно привязывать к этим высокоуровневым моделям.
Как правило, руководители и сотрудники бизнес-подразделений находят задачу
понимания архитектуры трудной и требующей слишком больших затрат времени. Действительно, за пределами служб ИТ роль и связующий фактор архитектуры предприятия зачастую не осознается, а взаимосвязи между данными являются
непонятными. Поэтому архитекторы нуждаются в простых, высокоуровневых средствах описания активностей и зависимостей в терминах, которые понятны бизнес-руководителям и пользователям и которые показывают соответствия с выполняемыми ими ролями. Графические бизнес-модели являются исключительно полезными в решении этой коммуникационной проблемы. Такие модели являются идеальным способом объяснить на достаточно высоком уровне критические активности и взаимосвязи в терминах бизнеса, и при этом они не
требуют знаний в области ИТ. Модели обеспечивают важную связь между бизнес-целями и стратегиями деятельности организации и многими вариантами реализации ИТ. Модели бывают различных типов: модели процессов/потоков работ, функциональные модели, организационные модели, модели данных/
ресурсов, временные модели типа диаграмм Ганта, модели причинно- следственных связей. Факт заключается в том, что нет «одной, самой лучшей»
модели для описания бизнес-процессов. Можно провести аналогию с графиками, которые используются для иллюстраций. Круговая диаграмма с сегментами, пропорциональными по размеру проценту чего-либо целого, отлично подходит для определенных задач, но ее нельзя использовать для иллюстрации и анализа всех типов данных. Точно также при анализе бизнес-процессов выбранный метод моделирования должен отражать цели анализа.
Оптимизация процесса по времени и четкий анализ взаимодействия между участниками процесса могут потребовать разных моделей.
Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architeсt, BPWin (новое название – AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно.
Основное внимание при разработке Бизнес-архитектуры должно уделяться «картине в целом». Целью Бизнес-архитектуры не является детальное описание деятельности предприятия. Модели, включенные в Бизнес-архитектуру, должны давать необходимый минимум сведений о ключевых функциях, процессах, бизнес-
событиях и потоках информации, достаточный для процесса принятия решений, поиска новых возможностей для инноваций. Дальнейшая детализация выполняется с использованием таких инструментов, как:

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

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

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

бизнеса;

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

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

• Анализ цепочек создания добавочной стоимости (А нужно ли вообще выпол-

нять этот шаг?)

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

Такие модели обычно имеют прямой выход на процесс генерации архитектуры приложений, как это предполагается в подходе разработки архитектуры, управляемой моделями (MDA). Безусловно, существует и множество других инструментов и моделей, полезных для более глубокого и более технологичного моделирования бизнес-процессов. В частности, могут использоваться контекстные диаграммы, диаграммы информационных потоков, а также конструкции и возможности языка UML, такие как сценарии использования, диаграммы последовательно-сти, диаграммы деятельности и др. Подробное описание этих средств выходит за рамки данного курса.
Мы уже отмечали, что показатели эффективности являются важной составляющей бизнес-архитектуры. Практически все модели, связанные с
показателями эффективности бизнеса и процессов, используют несколько уровней метрик: метрики оценки «качества» самого процесса, метрики для
оценки прямых результатов (output), метрики для оценки конечных результатов.
Метрики уровня процессов оценивают эффективность самого процесса. Типичными метриками являются время цикла выполнения операций, стоимость на транзакцию или единицу выхода процесса. Метрики оценки прямых результатов оценивают возможности процессов производить на выходе продукт или услугу в соответствии со спецификациями.
Типичными метриками оценки прямых результатов являются процент ошибок и количество обслуженных заявок в единицу времени. Метрики оценки конечных результатов оценивают процесс с точки зрения конечного потребителя (клиента) и выполнения функций организации. Примерами таких метрик являются уровень
удовлетворенности клиента и эффективность продукта.
В связи с развитием принципов сервис-ориентированной архитектуры и появлением технологически нейтрального, платформенно-независимого языка описания и выполнения бизнес-процессов BPEL (Business Process Execution
Language) появилась возможность не только моделировать бизнес-процессы, но и делать их целиком или частично доступными другим системам и организациям в виде сервисов.
К этому можно добавить также возможности еще одного стандарта XML Metadata Interchange (XMI) для обмена (экспорта/импорта) данных практически в любые интеграционные продукты. В совокупности это дает возможность создавать
модели и репозитории бизнес-процессов для их эффективной интеграции. Более подробную информацию о новых стандартах для моделирования процессов можно найти на сайте www.bpmi.org.
Бизнес-архитектура является основным инструментом синхронизации потребностей бизнеса и возможностей ИТ. В контексте архитектуры предприятия в целом разработка бизнес-архитектуры состоит в моделировании «картины в
целом» и последующем углублении в тщательно отобранные ключевые процессы и информационные потоки, в том числе с использованием таких инструментов, как декомпозиция функций/процессов, анализ бизнес-событий, модели местоположений и модели интеграции.