Бизнес архитектура предприятия описывает как

Время на прочтение
6 мин

Количество просмотров 2.8K

Бизнес-архитектура и ее место в компании

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

Таким образом, архитектура в городе — это наука не только о строительстве и проектировании, но еще и о структурировании.

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

Согласно методологии TOGAF, через бизнес‑архитектуру происходит постановка бизнес‑целей и управление ИТ‑архитектурой. Она связывает стратегию и тактику, помогает лучше понять потребности в целом.

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

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

Взгляд со стороны ИТ

Зачем вообще разрабатывать единую архитектуру для работы компании? Рассмотрим этот вопрос с точки зрения Блока информационных технологий Страхового Дома ВСК.

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

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

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

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

Основные бизнес-составляющие

Так случилось, что в один момент ИТ‑архитектура нашей компании устарела и перестала отвечать на вызовы рынка. Развитие ее стало долгим, дорогим и мучительным. Появилась явная цель — избавиться от старых приложений (legacy out) и реализовать новые.

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

Сервисы

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

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

В методологии Agile, во фреймворке SAFe, есть понятие «Value stream». Это картирование — сбор и анализ информации о процессах в потоке, оптимизация операций с точки зрения ценности действий и целесообразности затрат. Ценность рассматривается с точки зрения клиента.

Можно сказать, что наши сервисы — это маленькие велью стримы. Они нарезаны вокруг услуги, продукта, канала продаж и взаимодействий.

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

Способности

Способность (Capability) — это умение (или навык) компании. Мы только начинаем работу в этом направлении. На данный момент совместно с Ассоциацией ФинТех (далее — АФТ) разработан драфт функциональной карты страхового рынка. На ее основании реализован каталог способностей до 3 уровня.

Каждую из способностей можно детализировать на бизнес‑функции (4ый уровень) и смаппировать на сервисы. Такой подход обеспечит связь сервисов и бизнес‑процессов.

Дашборды

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

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

Архитектура решения

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

Фронт работ над ПО: развитие функционала по первичному учет сервисов, интеграция с Jira, автоматическое обновление дашбордов, формирование требований и разработка функционала по работе со способностями.

Касательно сервисов, важно отметить следующие пункты:

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

• для каждой задачи в Jira необходимо указать сервис и/или способность;

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

  

Перспективы развития

В 2022 году мы определили целевую концепцию и разработали базовый функционал по сервисам. Далее рассматриваем следующий план взаимодействия с Бизнесом:

• ИТ дорабатывает инструмент, осуществляет первичное наполнение данными и использует дашборды для общения с Бизнесом об уровне и качестве автоматизации;

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

Стратегия развития бизнес‑архитектуры следующая:

• первичный сбор данных и визуализация: ручной ввод данных об уровне и качестве автоматизации → визуализация данных, облегчение понимания где мы;

• автоматизация сбора информации: автоматизация сбора данных об уровне и качестве автоматизации на основании сервисов, сбор статистики по сервисам → автоматизация ручного ввода;

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

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

Заключение

Выше описан взгляд Страхового Дома ВСК на организацию бизнес‑архитектуры и практический подход к реализации.

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

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

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

Если у Вас есть интерес — пишите skirillov@vsk.ru

Что такое бизнес-архитектура?

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

Бизнес-архитектура дает ответы на многие вопросы, среди которых:

• Что делает бизнес? 
• Каким образом бизнес производит и доставляет ценность потребителю? 
• Как бизнес взаимодействует с поставщиками и потребителями? 
• Как организационные единицы и другие элементы бизнеса взаимодействуют между собой? 
• Какие термины и какой информацией оперируют участники бизнеса?  

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

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

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

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

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

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

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

Бизнес-архитектура может быть рассмотрена только в рамках компании целиком. 

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

Составляющие бизнес-архитектуры

Существует разница между понятиями «бизнес» и «корпоративная архитектура».

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

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

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

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

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

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

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

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

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

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

Чтобы не пропустить выход новых статей, подписывайтесь на наш телеграмм канал или группу в ВК. 

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

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

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

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

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

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

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

Построение бизнес — архитектуры начинается
с описания контекста бизнес — архитектуры
(рисунок 1.8.).

Общее видение бизнес — архитектуры
предприятия включает анализ основных
функций, цепочек создания добавленной
стоимости (ValueLandscapeAnalysis), модели бизнес –
сценариев (BusinessScenarioModels), анализ информационных
связей и процессов (InformationValueChainAnalysis).

Рисунок 1.8.
Контекст бизнес архитектуры

Основу архитектуры предприятия
составляет: анализ бизнес событий
(BusinessEventAnalysis), декомпозиция функций
и процессов (Function/ProcessDecomposition), модель расположения
(LocationModel),
модель интеграции (IntegrationModel).

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

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

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

• Динамические модели бизнес-процессов,
  включающие детализированное описание
  функционирования компании.

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

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

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

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

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

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

• выделить ключевые бизнес-процессы;

• выделить дублирующие бизнес-процессы
  и точки их пересечения.

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

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

Модель интеграцииопределяет связь
бизнес-процессов и бизнес — событий.

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

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

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

4. ИТ — архитектура
предприятия

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

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

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

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

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

• Enterprise Information Architecture (EIA) –
  информационная архитектура.

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

• Enterprise Technical Architecture (ETA) –
  техническая архитектура.

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предпосылки трансформации

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

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

Что делает архитектор

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

• описать текущее состояние предприятия (As IS),
• разработать его целевое состояние (To Be),
• разработать программу трансформационных проектов (Road Map).

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

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

Разработка целевого состояния предприятия

Первый этап: постановка бизнес-задач

В нашем примере с производственной компанией бизнес-задач четыре:

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

Второй этап: проработка будущего ландшафта информационных систем

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

Архитектор:

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

Третий этап: проектирование инфраструктуры

Разобравшись с данными и необходимыми прикладными средствами (ПО), архитектор проектирует для них инфраструктуру.

При проектировании инфраструктуры ему важно учесть три момента.

1. Обеспечить работоспособность систем при сбоях

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

2. Предусмотреть новые роли в производстве

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

3. Обеспечить информационную безопасность

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

Теперь можно говорить, что целевое состояние описано.

Разработка программы трансформационных проектов («дорожная карта»)

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

• развитие системы управленческого учета,
• разработать кадровую политику,
• создать подразделение ИТ-бизнес-партнеров,
• мигрировать CRM на новую платформу,
• модернизировать функциональность систем автоматизированного проектирования (САПР),
• внедрить практики управления сервисами,
• резервировать системы управления базами данных (СУБД) и т.д.,

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

Дальнейшие шаги

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

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

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

Как найти архитектора

Перед владельцами бизнеса встает резонный вопрос: а где найти специалистов по архитектуре предприятия? Есть два пути.

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

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

Напоследок рассмотрим, какие задачи архитектор может решить в ретейле и банковской сфере.

Пример: архитектурный подход в ретейле