Первым бизнес‑архитектором организации является ее основатель (неизвестный автор)

Управление корпоративной архитектурой — это та тема, в который на данный момент больше всего «тумана», несмотря на присутствие стандартов и лучших практик (TOGAF, BIZBOK и другие фреймворки).

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

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

Что такое управление?

Итак, начнем, наводя фокус на понятие корпоративной архитектуры в общем и бизнес‑архитектуры в частности, я пошел от простых управленческих понятий.

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

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

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

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

Какими объектами будем управлять?

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

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

Чаще всего можно встретить следующие объекты бизнес‑архитектуры внутри организации, я их называю объекты RUN:

• Продукты (продукты/услуги/сервисы и т. д.)

• Деятельность (процессы/функции/бизнес‑способности и т. д.)

• Исполнители (подразделения/роли/компетенции и т. д.)

• Информация (данные и т. д.)

Если выйти за рамками бизнес‑архитектуры, то на уровне корпоративной архитектуры можно, как минимум выделить следующие объекты управления в зоне ИТ:

• ИТ‑сервисы

• Информационные системы

• Программное обеспечение

• Оборудование

• и т. д.

Про внешние объекты

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

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

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

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

Про объекты Change

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

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

Для сервисной организации я бы выделил следующие объекты CHANGE:

• Цели, как верхнеуровневое описание целевого состояния организации

• Достижения (в том числе KPI), как описание результата достижения целей

• Инициативы (проекты/программы/портфели) — действия по трансформации организации

• Требования — детальное описание целевого состояния объекта управления

Взаимосвязь объектов управления

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

Между объектами RUN тоже есть связи: под потребности сегмента клиентов (внешний объект) мы подстраиваем продуктовую линейку, продукты, как результат деятельности (процессов) создаются исполнителями, внутри деятельности циркулируют информационные потоки, содержащие информацию.

Да, чуть не забыл, что объекты RUN связаны не только между собой, но и с объектами CHANGE, и бизнес‑архитектору по‑хорошему нужно понимать, какие объекты RUN какими объектами CHANGE изменяются.

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

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

Про изменения

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

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

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

Про цепочку трансформации

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

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

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

Здесь я остановлюсь, и подожду вопросов от читателей, чтобы понять, что мне детальнее раскрыть в следующей части статьи. Продолжение следует…

Таким образом, бизнес‑архитектура — это не абстрактная теория, а практический инструмент согласования целей, процессов и изменений внутри организации. Чтобы глубже разобраться в подходах и освоить проверенные методики, приглашаю присоединиться к курсу Otus «Enterprise Architect», на котором я преподаю.

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