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

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

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

Из статьи вы узнаете:

Что такое бизнес-архитектура, и кто отвечает за её проектирование
Какие типовые мифы существуют о бизнес-архитектуре
С какими проблемами сталкиваются бизнес-архитекторы в работе
Какие фундаментальные решения должны быть приняты в компаниях для управления бизнес-архитектурой
О наиболее часто используемых методологиях (TOGAF и ArchiMate) для проектирования бизнес-архитектуры
Как выглядит на практике построение бизнес-архитектуры

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

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

Бизнес-архитектура (далее БА) — это совокупность социальных групп, их взаимодействий, правил этих взаимодействий и фундаментальных принципов организации групп и взаимодействий.

TOGAF — методология управления БА

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

В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов: Business, Data, Application, Technology.

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

участие каждого из приложений в бизнес-процессах компании
взаимодействие приложений друг с другом и внешними сервисами

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

Эта часть фреймворка TOGAF условно называется статической.

Бизнес и ИТ-архитектура предприятия

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

Корпоративная архитектура в методологии TOGAF

На предварительной фазе цикла определяются фундаментальные вопросы: нужен ли TOGAF и в каком объёме, кто будет принимать решения. К моменту запуска полноценного архитектурного цикла обязательно должны быть описаны и формализованы текущее состояние БА и ИТ-архитектуры.

На стадии A. Архитектурного видения создаётся дорожная карта неудовлетворённостей: что не нравится, почему не нравится, что планируется с этим делать, какими средствами планируется это делать, какие есть ограничения.

Далее, на стадиях B. Архитектура бизнеса, С. Архитектуры информационных систем, D. Архитектура технологии происходит проектирование целевого состояния для реализации архитектурного видения.

На фазах E. Возможности и решения и F. Планирование миграции определяется набор возможных средств для достижения целевой архитектуры и мероприятия для перехода из текущего состояния архитектуры в целевое.

Фазы G. Управление реализацией и H. Управление изменением архитектуры отвечают за исполнение. В конце цикла проводится аудит результатов и запускается новый цикл.

ArchiMate — язык описания бизнес-процессов

Для моделирования бизнес-архитектуры дополнительно имеет смысл использовать язык ArchiMate. Он был разработан в The Open Group, создавшей стандарт архитектуры предприятия TOGAF.

Соответствие описания уровней архитектуры в стандартах TOGAF и ArchiMate

Язык ArchiMate дополняет методику и инструментарий TOGAF визуальным языком описания архитектуры, как внутри, так и между бизнес-областями. Уровни описания архитектуры в ArchiMate соответствуют разделению, принятому в TOGAF, поэтому их совместное использование позволяет комплексно описать архитектуру предприятия.

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

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

На рисунке ниже представлена модель этого процесса в TOGAF, реализованная языком ArchiMate.

Модель бизнес-процесса, реализованная с использованием языка Archimate

Давайте подробнее рассмотрим эту модель бизнес-процесса:

ФИО сотрудника — это конкретный человек, являющийся инициатором запуска бизнес-процесса;
Менеджер по закупкам — роль, которую выполняет сотрудник;
Логистика — функция, за которую отвечает сотрудник;
Стратегическая закупка — процесс, находящийся внутри функции и являющийся его неотъемлемой частью;
Контракт с оптимальными параметрами (напр. по минимальной цене и с максимальной отсрочкой платежей) — сервис, представляющий из себя ключевую ценность бизнес-процесса.
Запуск процесса в Битрикс24 — интерфейс для доступа к сервису другими сотрудникам компании.

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

Связь бизнес-архитектуры с другими частями корпоративной архитектуры

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

За каждым «сервисом на уровне бизнеса» стоит «сервис на уровне системой архитектуры». А за каждым «сервисом системной архитектуры» — «сервис уровня технологической архитектуры».

Связь БА с другими частями корпоративной архитектуры

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

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

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

Пример того, как сервисы на одном уровне могут потреблять ценность на другом уровне

Мифы о бизнес-архитектуре

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

БА создаёт сама себя и растёт вместе с компанией;Не может социальная система породить из самой себя структуру высокого уровня самоорганизации. Чаще всего это приводит к большому количеству неформальных связей, которые строятся на взаимных договоренностях. Организовать участников социальных систем могут либо компетентные органы управления, либо автократический лидер. В подавляющем большинстве случаев это автократический лидер, который впоследствии передаёт свою власть компетентному органу управления Руководящий состав компании ждёт документацию по БА от бизнес-аналитика;Руководителям в компании нет дела до документов, которые пишет бизнес-аналитик. Они ждут, что бизнес-аналитик облегчит им работу и всё организует без их участия. Бизнес-аналитик может сделать что–то такое, что сделает компанию эффективной;Бизнес-аналитик не обладает нужными для этого компетенциями. К тому же, в одиночку сделать компанию эффективной не сможет никто. БА изменяется во множестве точек самыми разными сотрудниками, и это хорошо;На самом деле это плохо, потому что совокупность компонентов, правил и связей всё время меняется и нет никого, кто бы точно знал, как сейчас всё это работает. Если в компании есть управление ИТ-архитектурой, это значит, что есть и управление БА;Проблема в том, что управление БА не входит ни в компетенции, ни в обязанности ИТ-архитектора. Это масштабная работа, которую должен выполнять специально нанятый для этой работы бизнес-архитектор. Даже если БА не формализована, архитектура данных всё равно есть;Архитектуры данных быть не может, так как если БА постоянно меняется, то неизвестно, какие данные нужны для эффективного прохождения процесса. Под архитектурой данных мы понимаем правила, которые определяют, какие данные собираются в компании, и как они хранятся. Подразделения сами договорятся друг с другом по всем вопросам и этого будет достаточно для бесперебойного исполнения бизнес-процессов;Рассмотрим на примере взаимодействия отделов производства и закупки. Отдел производства просит отдел закупок купить определённые запчасти в течении 3 недель. Отдел закупок может выполнить эту задачу только через 3 месяца, так как эти запчасти импортные, и срок их доставки зависит от иностранного партнёра. К тому же, у отдела закупок есть своя очередь по обработке заявок, которые тоже ждут, и ограниченное количество ресурсов. Таким образом возникает конфликт, в котором нет виноватых. Этой ситуации бы не возникло, если бы был прописан SLA (Service Level Agreement — документ, описывающий параметры предоставляемых услуг). SLA является частью БА.

Типовые проблемы, с которыми сталкивается бизнес-архитектор

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

Сотрудники компании сопротивляются введению централизованного управления БА;Чаще всего это воспринимается сотрудниками не как оптимизация, а как неудовлетворительность текущей организацией работы сотрудников. К тому же, как только обсуждение процессов выходит за пределы личных договорённостей, то у руководящих сотрудников возникает ощущение, что они лишаются власти. Отдельные сотрудники единолично вносят изменения на различных уровнях ИТ-архитектуры;В компании нет строгих правил, определяющих когда и как можно вносить изменения в процессы, чтобы все заинтересованные стороны могли спланировать работы. Отделу кадров сложно прописать полномочия бизнес-архитектора;Эта профессия скорее творческая, так как бизнес-архитекторы не просто документируют существующую БА, а зачастую являются инициаторами изменений: перестраивают существующие процессы, создают новые, упраздняют неактуальные. В долгосрочной перспективе всё это должно привести к развитию организации. В штатном расписании нет сотрудника, ответственного за социальные взаимодействия между подразделениями и персоналом;Обычно руководство компании не видит смысла в подобной должности, ведь при необходимости сотрудники могут и сами взаимодействовать между собой. Однако, трансформация, которую проходит корпоративная архитектура, неуклонно затрагивает людей и требует от них дополнительных усилий, обучения и так далее. Организация этих процессов должна вестись компетентной службой.

Фундамент решений, которые необходимо принять для проектирования БА

Как только руководство компании принимает решение о необходимости проектирования БА и найме для этого соответствующих сотрудников, оно должно быть готово предпринять следующие действия:

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

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

3. Формализовать сервисы и интерфейсы между службами и подразделениями
Требуется чётко сформулировать: кто, что, кому, когда и в каком объёме должен предоставлять и получать.

4. Формализовать БА и управлять изменениями в ней.
Бизнес-архитектор нужен, чтобы цельно и понятно описать БА и утвердить в архитектурном комитете. После этого изменения в неё должны вноситься централизованно, никто не должен вносить изменения в процессы самовольно. Исключение составляют критические ситуации и высшее руководство компании, после согласования с генеральным директором. Все участники процесса должны знать правила игры, а не догадываться.

5. Централизованно управлять не только БА, но и ИТ-архитектурой компании.
И тем, и другим надо управлять в единстве.

Этапы проектирования бизнес-архитектуры

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

С чего нам стоило бы начать при проектировании этого процесса? Как и в работе с ПО, мы начнем со сбора функциональных требований, нефункциональных требований и ограничений. Например, так:

ФТ: процесс должен обеспечивать передачу материалов со склада в производство.
НФТ: один экземпляр процесса должен осуществляться не дольше, чем 30 мин.
Ограничение: процесс должен выполняться силами не более, чем 3 сотрудников.

Далее, стоит составить подробное описание текущего состояния бизнес-архитектуры. Нужно подумать о том, какие существуют процессы рядом с нашим, проектируемым? С какими из них нужно будет взаимодействовать и как? Какие будут использованы интерфейсы доступа к сервису, который наш процесс создаёт? И один из важнейших вопросов: какой будет ценность, создаваемая бизнес-процессом?

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

Например, на первой фазе процесса «Передача материалов со склада в производство», в стадии MVP, мы можем спроектировать процесс так: сотрудники относят материалы в производство на руках. Затем, наблюдая за ситуацией, мы видим, что объём материалов растёт и процесс замедляется, необходимо внести коррективы.

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

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

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

Подведём итоги

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

Вопросы и ответы

Вопрос:

Где можно применять TOGAF в реальной практике?

Ответ:

TOGAF может быть применён в любой организации, как коммерческой, так и некоммерческой. Другое дело, что до его использования компания должна «дорасти».
Вопрос:

Что должен знать и понимать о бизнес-архитектуре системный аналитик, product owner?

Ответ:

Если речь про заказную разработку, то product owner и аналитик должны знать о бизнес-архитектуре заказчика всё, потому что иначе этот программный продукт будет бесполезен.

Если речь о продуктовой разработке, то здесь они должны спроектировать и задокументировать ту бизнес-архитектуру, которую будут цифровизировать в рамках решения. Описать, что решение предоставляет сервисы application data services для бизнес-сервисов на уровне этой бизнес-архитектуры, и потребляет некие технологические сервисы. Когда наступит этап продажи продукта, то можно будет понять, насколько та БА, которая легла как модель для формализации требований к продукту, отличается от БА клиента, и можно ли адаптировать продукт под клиента. Если у вас нет этой БА, то в процессе реального внедрения будет много проблем.
Вопрос:

Чем БА отличается от ИТ-архитектуры?

Ответ:

БА — это совокупность социальных компонентов, и она содержит в себе неотъемлемый компонент — иррациональные взаимодействия, за который отвечает HR. ИТ-архитектура — это техническая составляющая, и если всё формализовано, то работать она будет именно так, как её формализовали. В БА, если не поставлена работа с иррациональным взаимодействиями, то работать она будет непредсказуемо, невзирая на формализацию.
Вопрос:

Что первично, БА или ИТ-архитектура?

Ответ:

Однозначно, БА первична, потому что она генерирует денежный поток. При этом надо помнить, что в наше время БА без ИТ-архитектуры просто не жизнеспособна.

Автор

Александр Кварцхава

Директор по управлению IT и корпоративной архитектурой

Менеджер, корпоративный архитектор, архитектор 1С, 10 лет в IT.

Эксперт по конфигурации 1С ERP и смежным решениям.

Прошёл путь от линейного аналитика до корпоративного архитектора и IT директора.