Простая истина: чем комфортнее и красивее город, тем более приятно и удобно в нем жить. Архитектура города — это не только архитектура конкретных зданий и сооружений, но и сама их совокупность, создающая пространственную среду для жизни и деятельности человека. И чем лучше структурировано пространство вокруг в части зданий, маршрутов, оказываемых услуг — тем нам удобнее. Таким образом, архитектура в городе — это наука не только о строительстве и проектировании, но еще и о структурировании. Также на предприятии. Бизнес‑архитектура – это целостная и интегрированная модель компании, которая связывает стратегические, структурные, технологические и информационные аспекты. Она есть всегда и является частью корпоративной архитектуры. Согласно методологии TOGAF, через бизнес‑архитектуру происходит постановка бизнес‑целей и управление ИТ‑архитектурой. Она связывает стратегию и тактику, помогает лучше понять потребности в целом. Структурирование разрозненной бизнес‑информации, связь ее элементов в целостные группы необходимы для формирования бизнес‑ландшафта. Чем понятнее бизнес‑ландшафт, тем удобнее управлять им и, как следствие, компанией. Управление бизнес‑архитектурой — это процесс, которым нужно заниматься: своевременно обновлять данные, обрабатывать и анализировать их. Из этих же данных, например, обычно формируется бизнес‑стратегия. Зачем вообще разрабатывать единую архитектуру для работы компании? Рассмотрим этот вопрос с точки зрения Блока информационных технологий Страхового Дома ВСК. Во‑первых, часто бывают случаи, когда Заказчик и Исполнитель смотрят по‑разному на одну и ту же автоматизацию. Поэтому единый взгляд очень важен, как и единое мерило (которое имеет однозначное трактование «да» или «нет). Во‑вторых, сейчас десятилетие автоматизации и цифровизации. Идет большой объем перевода еще некогда ручных процессов в «цифру». И чем более понятен бизнес‑ландшафт, тем более качественные решения принимаются до начала автоматизации (без последующих переделок или решений «в ведро»). Поэтому для нас целью внедрения бизнес‑архитектуры являются формирование в Компании единого прозрачного понимания уровня автоматизации бизнес‑ландшафта и переход к управлению ИТ‑архитектурой через бизнес‑составляющие. При проектировании решения важна не только детализация требований в постановке на автоматизацию, но и понимание того, как это повлияет на бизнес‑ландшафт. Порой непонимание уже реализованного функционала приводит к его дублированию или реализации его в непрофильных системах. Поэтому появляется ИТ‑зоопарк. Чтобы этого избежать нужна бизнес‑архитектура и приземление всех задач на автоматизацию через бизнес‑ландшафт. Так случилось, что в один момент ИТ‑архитектура нашей компании устарела и перестала отвечать на вызовы рынка. Развитие ее стало долгим, дорогим и мучительным. Появилась явная цель — избавиться от старых приложений (legacy out) и реализовать новые. Это очень непростая задача, так как старые приложения выключать можно только после полного перевода функционала в новые. А это множество каналов продаж, страховых продуктов и услуг, агентов и партнеров компании. Но кроме самого перевода появилась еще одна важная задача — понять и выяснить, что такое полный перевод. И сколько нужно времени для его выполнения. Работая над переводом функционала устаревших приложений в целевую архитектуру, мы определи такой элемент как сервис. Если бизнес‑процесс — это графическое описание последовательности шагов, выполняемых сотрудниками по одной или нескольким бизнес‑функциям, а его цель — повышение эффективности процессов компании; то сервис — это услуга, предоставляемая клиенту и имеющая для него ценность. Основная цель сервиса — повышение клиентоориентированности. В методологии Agile, во фреймворке SAFe, есть понятие «Value stream». Это картирование — сбор и анализ информации о процессах в потоке, оптимизация операций с точки зрения ценности действий и целесообразности затрат. Ценность рассматривается с точки зрения клиента. Можно сказать, что наши сервисы — это маленькие велью стримы. Они нарезаны вокруг услуги, продукта, канала продаж и взаимодействий. Сервис состоит из тех показателей, которые оценивают качество. Именно на их основании сегодня есть возможность расчета как процента перехода в целевую архитектуру, так и уровня, и качества автоматизации. Способность (Capability) — это умение (или навык) компании. Мы только начинаем работу в этом направлении. На данный момент совместно с Ассоциацией ФинТех (далее — АФТ) разработан драфт функциональной карты страхового рынка. На ее основании реализован каталог способностей до 3 уровня. Каждую из способностей можно детализировать на бизнес‑функции (4ый уровень) и смаппировать на сервисы. Такой подход обеспечит связь сервисов и бизнес‑процессов. Речь идет о визуализации показателей в информационном разрезе компании. Дашборды представляют собой матрицу, имеют цветовую идентификацию и возможность Drill Down. Цель реализации: быстро определить те разрезы, которые требуют улучшения, и получить картину того, какие существуют недочеты и слабые места. Первично весь учет и отчетность по сервисам мы вели в Excel, где были тысячи строк и сотни столбцов. Работая на удобством и новыми требованиями, которые не возможно реализовать в Excel, мы начали работу над ПО для управления бизнес‑архитектурой. Фронт работ над ПО: развитие функционала по первичному учет сервисов, интеграция с Jira, автоматическое обновление дашбордов, формирование требований и разработка функционала по работе со способностями. Касательно сервисов, важно отметить следующие пункты: по каждому сервису необходимо определить реального владельца, отвечающего за его развитие; для каждой задачи в Jira необходимо указать сервис и/или способность; дашборды должны стать инструментом визуализации для планирования и развития. В 2022 году мы определили целевую концепцию и разработали базовый функционал по сервисам. Далее рассматриваем следующий план взаимодействия с Бизнесом: ИТ дорабатывает инструмент, осуществляет первичное наполнение данными и использует дашборды для общения с Бизнесом об уровне и качестве автоматизации; если Бизнес не согласен с предоставленной информацией, то через ответственных осуществляется ее корректировка. Стратегия развития бизнес‑архитектуры следующая: первичный сбор данных и визуализация: ручной ввод данных об уровне и качестве автоматизации → визуализация данных, облегчение понимания где мы; автоматизация сбора информации: автоматизация сбора данных об уровне и качестве автоматизации на основании сервисов, сбор статистики по сервисам → автоматизация ручного ввода; прогнозирование изменения конъюнктуры: апробирование гипотез и трендов — цифровой двойник* → наличие модели, помогающей предсказывать последствия планируемых изменений. * Цифровой двойник — это виртуальная модель любых объектов, систем, процессов или людей, которая состоит из физического продукта в реальном пространстве, цифрового продукта в виртуальном пространстве, данных и информации, которые объединяют цифровой и физический продукты. Выше описан взгляд Страхового Дома ВСК на организацию бизнес‑архитектуры и практический подход к реализации. Сейчас появляется все больше активностей, которые активно развиваются и создают поводы для обсуждения: в рамках импортозамещения ЦБ формирует функционально технологическую карту, а АФТ интересно развитие функциональной карты для страхового рынка как некого мерила и светофора его автоматизации.  Также работа с бизнес‑архитектурой является трендом и, скорее всего, Вы тоже с ней работаете или начинаете развивать этот направление. Мы с радостью готовы услышать о похожем или, наоборот, отличающемся опыте и результатах работы над организацией бизнес‑архитектуры, различных подходах к реализации и новостях в этой сфере. Если у Вас есть интерес — пишите skirillov@vsk.ru