Статья подготовлена в рамках курса «Директор информационных технологий / CIO».

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

Что же такое бизнес‑архитектура

Если посмотреть какие инструменты сейчас в моде у корпоративных архитекторов, то можно увидеть Capability Map (карту способностей) и Value Stream (поток создания ценности) с помощью которых можно посмотреть на организацию с двух точек зрения, с точки зрения ценности, доставляемой клиентам, и с точки зрения способностей организации (функциональная «нарезка» деятельности), поддерживавших поток создания ценности. Поток создания ценности и карта способности — это точки зрения на Run деятельность организации, то есть мы понимаем, как организация работает сейчас, после чего определяем целевое состояние.

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

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

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

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

Показатели «правильной» бизнес‑архитектуры

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

1. Согласованность с внешним миром

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

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

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

Для корпоративной архитектуры важна обоснованность изменения и приоритеты изменений:

• Проверяем синхронизацию объектов от Клиента: Потребности клиентов ➙ Продукты организации ➙ Процессы организации ➙ ИТ‑приложения. При нахождении несоответствий можем получить снижение затрат на автоматизацию невостребованных продуктов и процессов.

• Проверяем синхронизацию объектов от внешних драйверов: Внешние драйвера ➙ Цели ➙ Проекты ➙ Процессы ➙ ИТ‑приложения. В результате анализа получаем приоритезацию инвестиций в ИТ относительно поставленных целей, «замораживая» остальные проекты.

2. Способность к изменениям 

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

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

Для корпоративной архитектуры в целом, и бизнес‑архитектуры в частности важна способность объектов Run‑деятельности к изменениям, поэтому предлагается анализировать следующие показатели:

• Среднее время изменения процесса и конверсия успеха изменения.

• Среднее время изменения ИТ‑приложения и конверсия успеха изменения.

• Среднее время изменения подразделения (штатной численности или компетенций) и конверсия успеха изменения.

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

• Определяем масштаб и реалистичность изменения: Цель ➞ Проекты ➞ Процессы ➞ ИТ‑приложения и/или ➞ Подразделения.

• Определяем «бутылочное горлышко» изменения или противоречивые изменения: Цель ➞ Проекты ➞ Процесс, анализируя сколько проектов направлены на изменение одного процесса, и согласованы ли проекты друг с другом.

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

3. Эффективность организации

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

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

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

• Затраты на процессы, относительно выручки по связанным продуктам или стоимости аутсорсинга услуг.

• Загрузка сотрудников подразделений относительно нормативов загрузки.

• Количество активных пользователей ИТ‑приложений относительно затрат на них.

• Уровень загрузки объектов инфраструктуры.

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

4. Надежность бизнеса

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

Для анализа с точки зрения корпоративной архитектуры тут мы поднимаемся «снизу‑вверх»: ИТ‑инфраструктура ➞ ИТ‑приложение ➞ Процесс.

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

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

Почему для ИТ важно понимать бизнес‑архитектуру

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

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

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

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

Почему бизнес‑архитектурой начинают заниматься в ИТ

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

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

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

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

Не без проблем

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

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

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

Заглянем в далекое будущее

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

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

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

P.S. Для тех, кто готов переходить от теории к практике:

Примите участие в бесплатном вебинаре на тему «Значение корпоративной архитектуры для реализации стратегии цифровой трансформации» 21 апреля в 20:00. Это отличный шанс познакомиться с преподавателями курса и протестировать формат обучения.