Александр КВАРЦХАВА
Проблемы управления бизнес-архитектурой компании
Введение
В небольших компаниях взаимодействия между подразделениями часто строятся на устных договорённостях, задачи решаются индивидуально, решения принимаются ситуационно. Эта схема более или менее работает в компаниях, где мало сотрудников, есть авторитарный лидер, и бизнес-процессы допускается менять «по звонку руководства».
Если бизнес оказывается успешным, и компания расширяется, то рано или поздно возникает необходимость поиска оптимизационных решений в области организации деятельности. В компаниях начинают внедрять процессные модели управления, описывая деятельность предприятия в виде графических и текстовых бизнес-процессов.
Несмотря на все старания, они зачастую не приводят к каким-либо положительным изменениям в компании. Этому есть ряд причин. Среди основных можно выделить: нехватка опытных специалистов по построению и управления бизнес-архитектурой; отсутствие ответственных за управление социальными системами; мнение руководства, что что наличие ИТ-архитектуры достаточно для появления бизнес-архитектуры; неготовность руководящего состава к оценке существующих бизнес-процессов.
Если бизнес оказывается успешным, и компания расширяется, то рано или поздно возникает необходимость поиска оптимизационных решений в области организации деятельности. В компаниях начинают внедрять процессные модели управления, описывая деятельность предприятия в виде графических и текстовых бизнес-процессов.
Несмотря на все старания, они зачастую не приводят к каким-либо положительным изменениям в компании. Этому есть ряд причин. Среди основных можно выделить: нехватка опытных специалистов по построению и управления бизнес-архитектурой; отсутствие ответственных за управление социальными системами; мнение руководства, что что наличие ИТ-архитектуры достаточно для появления бизнес-архитектуры; неготовность руководящего состава к оценке существующих бизнес-процессов.
Из статьи вы узнаете:
- Что такое бизнес-архитектура, и кто отвечает за её проектирование
- Какие типовые мифы существуют о бизнес-архитектуре
- С какими проблемами сталкиваются бизнес-архитекторы в работе
- Какие фундаментальные решения должны быть приняты в компаниях для управления бизнес-архитектурой
- О наиболее часто используемых методологиях (TOGAF и ArchiMate) для проектирования бизнес-архитектуры
- Как выглядит на практике построение бизнес-архитектуры
Что такое бизнес-архитектура?
Бизнес-архитектура (далее БА) — это совокупность социальных групп, их взаимодействий, правил этих взаимодействий и фундаментальных принципов организации групп и взаимодействий.
TOGAF — методология управления БА
Одним из инструментов, использующихся для разработки и поддержания БА, является методология TOGAF. Её основное назначение — ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития.
В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов: Business, Data, Application, Technology.
В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов: Business, Data, Application, Technology.
- Бизнес архитектура — определяет стратегию предприятия, структуру управления и ключевые бизнес процессы.
- Архитектура данных — описывает логическую и физическую структуру данных организации, а также структуру корпоративных ресурсов для управления данными.
- Архитектура приложений — служит своеобразной картой всех используемых корпоративных приложений и определяет следующие аспекты:
- участие каждого из приложений в бизнес-процессах компании
- взаимодействие приложений друг с другом и внешними сервисами
4. Технологическая архитектура — определяет структуру и логику программного обеспечения и аппаратной среды, необходимых для работы бизнес приложений и доступа к нужным данным. Этот уровень включает всю поддерживающую инфраструктуру: сети, сервера, процессинг и т.п.
Эта часть фреймворка TOGAF условно называется статической.
Эта часть фреймворка TOGAF условно называется статической.
Бизнес и ИТ-архитектура предприятия
Динамическая часть фреймворка TOGAF представляет из себя цикл, который сводится к управлению изменениями.
Корпоративная архитектура в методологии TOGAF
На предварительной фазе цикла определяются фундаментальные вопросы: нужен ли TOGAF и в каком объёме, кто будет принимать решения. К моменту запуска полноценного архитектурного цикла обязательно должны быть описаны и формализованы текущее состояние БА и ИТ-архитектуры.
На стадии A. Архитектурного видения создаётся дорожная карта неудовлетворённостей: что не нравится, почему не нравится, что планируется с этим делать, какими средствами планируется это делать, какие есть ограничения.
Далее, на стадиях B. Архитектура бизнеса, С. Архитектуры информационных систем, D. Архитектура технологии происходит проектирование целевого состояния для реализации архитектурного видения.
На стадии A. Архитектурного видения создаётся дорожная карта неудовлетворённостей: что не нравится, почему не нравится, что планируется с этим делать, какими средствами планируется это делать, какие есть ограничения.
Далее, на стадиях B. Архитектура бизнеса, С. Архитектуры информационных систем, D. Архитектура технологии происходит проектирование целевого состояния для реализации архитектурного видения.
На фазах E. Возможности и решения и F. Планирование миграции определяется набор возможных средств для достижения целевой архитектуры и мероприятия для перехода из текущего состояния архитектуры в целевое.
Фазы G. Управление реализацией и H. Управление изменением архитектуры отвечают за исполнение. В конце цикла проводится аудит результатов и запускается новый цикл.
Фазы G. Управление реализацией и H. Управление изменением архитектуры отвечают за исполнение. В конце цикла проводится аудит результатов и запускается новый цикл.
ArchiMate — язык описания бизнес-процессов
Для моделирования бизнес-архитектуры дополнительно имеет смысл использовать язык ArchiMate. Он был разработан в The Open Group, создавшей стандарт архитектуры предприятия TOGAF.
Соответствие описания уровней архитектуры в стандартах TOGAF и ArchiMate
Язык ArchiMate дополняет методику и инструментарий TOGAF визуальным языком описания архитектуры, как внутри, так и между бизнес-областями. Уровни описания архитектуры в ArchiMate соответствуют разделению, принятому в TOGAF, поэтому их совместное использование позволяет комплексно описать архитектуру предприятия.
ArchiMate позволяет описать как построены и работают различные части предприятия, включая бизнес-процессы, организационные структуры, информационные потоки, ИТ-системы, а также техническую и физическую инфраструктуру.
В качестве примера давайте рассмотрим упрощённый бизнес-процесс по заключению контракта. Предположим, что процесс происходит в рамках стратегической закупки сырья, а его основная цель — заключение контракта с оптимальными параметрами в рамках процесса стратегической закупки сырья.
На рисунке ниже представлена модель этого процесса в TOGAF, реализованная языком ArchiMate.
ArchiMate позволяет описать как построены и работают различные части предприятия, включая бизнес-процессы, организационные структуры, информационные потоки, ИТ-системы, а также техническую и физическую инфраструктуру.
В качестве примера давайте рассмотрим упрощённый бизнес-процесс по заключению контракта. Предположим, что процесс происходит в рамках стратегической закупки сырья, а его основная цель — заключение контракта с оптимальными параметрами в рамках процесса стратегической закупки сырья.
На рисунке ниже представлена модель этого процесса в TOGAF, реализованная языком ArchiMate.
Модель бизнес-процесса, реализованная с использованием языка Archimate
Давайте подробнее рассмотрим эту модель бизнес-процесса:
- ФИО сотрудника — это конкретный человек, являющийся инициатором запуска бизнес-процесса;
- Менеджер по закупкам — роль, которую выполняет сотрудник;
- Логистика — функция, за которую отвечает сотрудник;
- Стратегическая закупка — процесс, находящийся внутри функции и являющийся его неотъемлемой частью;
- Контракт с оптимальными параметрами (напр. по минимальной цене и с максимальной отсрочкой платежей) — сервис, представляющий из себя ключевую ценность бизнес-процесса.
- Запуск процесса в Битрикс24 — интерфейс для доступа к сервису другими сотрудникам компании.
Связь бизнес-архитектуры с другими частями корпоративной архитектуры
Связь БА с другими частями корпоративной архитектуры осуществляется через интерфейсы. Очень часто интерфейсы путают с сервисами. Давайте внесем ясность в этот вопрос. Панель управления стиральной машинки — это интерфейс. Ценность его создается только реализацией всего сервиса. Именно сервис даёт нам ценность: без всей остальной стиральной машинки (сервис) нет смысла в панели управления ею (интерфейс). Но, обратите внимание, доступ к ценности даёт именно интерфейс: без панели управления (интерфейс) мы не можем воспользоваться машинкой (сервисом).
За каждым «сервисом на уровне бизнеса» стоит «сервис на уровне системой архитектуры». А за каждым «сервисом системной архитектуры» — «сервис уровня технологической архитектуры».
За каждым «сервисом на уровне бизнеса» стоит «сервис на уровне системой архитектуры». А за каждым «сервисом системной архитектуры» — «сервис уровня технологической архитектуры».
Связь БА с другими частями корпоративной архитектуры
Например, менеджеру нужно получить информацию о количестве товара на складе. Сервис «получение информации об остатках на складах» осуществляется через отчёт «ведомость по товарам на складе». Сам по себе отчёт — это интерфейс, не сервис. Как именно создаётся ценность от нас скрыто.
Бизнес-сервис может потреблять бизнес-сервис, то есть, сервисы на одном уровне могут потреблять ценность, создаваемую друг другом, но между уровнями связь осуществляется только через интерфейсы.
В качестве примера давайте посмотрим на сервис доставки продуктов на дом. В данном случае ключевая ценность состоит сразу из двух бизнес-сервисов «покупка продуктов» и «доставка на дом». По-отдельности эти сервисы покупателю не нужны. Клиенту не интересны купленные товары, которые продолжают лежать в магазине, или приехавший без продуктов курьер. Каждый из этих сервисов через интерфейсы связан со своими системным и технологическим уровнями для реализации бизнес-ценности.
Бизнес-сервис может потреблять бизнес-сервис, то есть, сервисы на одном уровне могут потреблять ценность, создаваемую друг другом, но между уровнями связь осуществляется только через интерфейсы.
В качестве примера давайте посмотрим на сервис доставки продуктов на дом. В данном случае ключевая ценность состоит сразу из двух бизнес-сервисов «покупка продуктов» и «доставка на дом». По-отдельности эти сервисы покупателю не нужны. Клиенту не интересны купленные товары, которые продолжают лежать в магазине, или приехавший без продуктов курьер. Каждый из этих сервисов через интерфейсы связан со своими системным и технологическим уровнями для реализации бизнес-ценности.
Пример того, как сервисы на одном уровне могут потреблять ценность на другом уровне
Мифы о бизнес-архитектуре
На практике я регулярно сталкиваюсь с самыми разнообразными мифами, касающимися бизнес-архитектуры. Если руководство компании позволяет себе верить в эти мифы, оно по сути бросает управление бизнес-архитектурой на самотёк. Постараемся развеять самые типовые мифы.
Типовые проблемы, с которыми сталкивается бизнес-архитектор
Когда бизнес-архитектор приступает к своим прямым обязанностям, то чаще всего он сталкивается с рядом противостояний, напрямую связанных с его деятельностью. Именно поэтому для бизнес-архитектора крайне важны такие навыки, как умение быть лидером, способность коммуницировать и убеждать.
Фундамент решений, которые необходимо принять для проектирования БА
Как только руководство компании принимает решение о необходимости проектирования БА и найме для этого соответствующих сотрудников, оно должно быть готово предпринять следующие действия:
1. Создать роль бизнес-архитектора в компании.
Стоит учесть, что бизнес-аналитик и бизнес-архитектор это две разные роли, имеющие разные обязанности. Бизнес-аналитик — это помощник бизнес-архитектора. Его задачи: проводить интервью, документировать, создавать концепты, перенимать опыт бизнес-архитектора. Бизнес-архитектор — аналитик, проектировщик и контролёр реализации.
2. Ограничить полномочия руководителей компании в пользу роли бизнес-архитектора в части проектирования реализации БА. Разделить на законодательную и исполнительную власти.
Архитектор — законодательная власть. Он формирует законы и утверждает их, самостоятельно или в архитектурном комитете. В архитектурный комитет могут входить топ-менеджеры и владельцы, в зависимости от договоренностей. Исполнительная власть это руководители подразделений, они оживляют эти законы и модель, реализуя изменения.
1. Создать роль бизнес-архитектора в компании.
Стоит учесть, что бизнес-аналитик и бизнес-архитектор это две разные роли, имеющие разные обязанности. Бизнес-аналитик — это помощник бизнес-архитектора. Его задачи: проводить интервью, документировать, создавать концепты, перенимать опыт бизнес-архитектора. Бизнес-архитектор — аналитик, проектировщик и контролёр реализации.
2. Ограничить полномочия руководителей компании в пользу роли бизнес-архитектора в части проектирования реализации БА. Разделить на законодательную и исполнительную власти.
Архитектор — законодательная власть. Он формирует законы и утверждает их, самостоятельно или в архитектурном комитете. В архитектурный комитет могут входить топ-менеджеры и владельцы, в зависимости от договоренностей. Исполнительная власть это руководители подразделений, они оживляют эти законы и модель, реализуя изменения.
3. Формализовать сервисы и интерфейсы между службами и подразделениями
Требуется чётко сформулировать: кто, что, кому, когда и в каком объёме должен предоставлять и получать.
4. Формализовать БА и управлять изменениями в ней.
Бизнес-архитектор нужен, чтобы цельно и понятно описать БА и утвердить в архитектурном комитете. После этого изменения в неё должны вноситься централизованно, никто не должен вносить изменения в процессы самовольно. Исключение составляют критические ситуации и высшее руководство компании, после согласования с генеральным директором. Все участники процесса должны знать правила игры, а не догадываться.
5. Централизованно управлять не только БА, но и ИТ-архитектурой компании.
И тем, и другим надо управлять в единстве.
Требуется чётко сформулировать: кто, что, кому, когда и в каком объёме должен предоставлять и получать.
4. Формализовать БА и управлять изменениями в ней.
Бизнес-архитектор нужен, чтобы цельно и понятно описать БА и утвердить в архитектурном комитете. После этого изменения в неё должны вноситься централизованно, никто не должен вносить изменения в процессы самовольно. Исключение составляют критические ситуации и высшее руководство компании, после согласования с генеральным директором. Все участники процесса должны знать правила игры, а не догадываться.
5. Централизованно управлять не только БА, но и ИТ-архитектурой компании.
И тем, и другим надо управлять в единстве.
Этапы проектирования бизнес-архитектуры
Проектирование бизнес-процессов очень похоже на разработку ПО и состоит из тех же самых фаз. Давайте посмотрим на примере проектирования бизнес-процесса «Передача материалов со склада в производство».
С чего нам стоило бы начать при проектировании этого процесса? Как и в работе с ПО, мы начнем со сбора функциональных требований, нефункциональных требований и ограничений. Например, так:
С чего нам стоило бы начать при проектировании этого процесса? Как и в работе с ПО, мы начнем со сбора функциональных требований, нефункциональных требований и ограничений. Например, так:
- ФТ: процесс должен обеспечивать передачу материалов со склада в производство.
- НФТ: один экземпляр процесса должен осуществляться не дольше, чем 30 мин.
- Ограничение: процесс должен выполняться силами не более, чем 3 сотрудников.
И только затем, исходя из собранных требований, описанного текущего состояния и формализованных целей — вот после всего этого имеет смысл переходить к реализации прототипа. Здесь, как и в разработке, начинать надо с MVP (Minimal Viable Product — минимально жизнеспособный продукт). Делаем прототип бизнес-процесса, проводим тестирование, собираем обратную связь и развиваем прототип процесса, совершенствуя тот сервис, над которым работаем. Очень важно придерживаться этих шагов.
Например, на первой фазе процесса «Передача материалов со склада в производство», в стадии MVP, мы можем спроектировать процесс так: сотрудники относят материалы в производство на руках. Затем, наблюдая за ситуацией, мы видим, что объём материалов растёт и процесс замедляется, необходимо внести коррективы.
Вы внедряем улучшение: теперь сотрудники перевозят материалы с помощью тележки. Если и этого оказалось недостаточно, на третьей фазе мы начинаем использовать какую-нибудь специальную машину для внутренней логистики. Но перескочить с первой фазы на третью, сразу закупить машину для перевозки материалов, может быть совершенно нецелесообразно, ведь на старте мы не знаем, как много будет материалов и не достаточно ли будет просто сил сотрудников.
Например, на первой фазе процесса «Передача материалов со склада в производство», в стадии MVP, мы можем спроектировать процесс так: сотрудники относят материалы в производство на руках. Затем, наблюдая за ситуацией, мы видим, что объём материалов растёт и процесс замедляется, необходимо внести коррективы.
Вы внедряем улучшение: теперь сотрудники перевозят материалы с помощью тележки. Если и этого оказалось недостаточно, на третьей фазе мы начинаем использовать какую-нибудь специальную машину для внутренней логистики. Но перескочить с первой фазы на третью, сразу закупить машину для перевозки материалов, может быть совершенно нецелесообразно, ведь на старте мы не знаем, как много будет материалов и не достаточно ли будет просто сил сотрудников.
Параллельно с проектированием БА должны прорабатываться изменения в остальных частях архитектуры компании. В первую очередь я имею ввиду, что нужно собрать информацию, о том, какие данные нужны для осуществления нашего процесса, откуда их получать, где регистрировать, и кто это будет делать.
Также уже на стадии проектирования прототипа нужно подключиться HR-лидеру. Он наполнит процесс сотрудниками, обучит их, замотивирует, будет отслеживать их внутреннее состояние. Это огромнейший объём работы, который не сделать ИТ-архитектору или корпоративному архитектору. Нередко процесс рушится, потому что роль HR-лидера просто никто не выполнил.
Также уже на стадии проектирования прототипа нужно подключиться HR-лидеру. Он наполнит процесс сотрудниками, обучит их, замотивирует, будет отслеживать их внутреннее состояние. Это огромнейший объём работы, который не сделать ИТ-архитектору или корпоративному архитектору. Нередко процесс рушится, потому что роль HR-лидера просто никто не выполнил.
Подведём итоги
- Бизнес-архитектура — это важнейшая часть корпоративной архитектуры и нуждается в полноценном законодательном управлении.
- Как правило, бизнес-аналитик не управляет бизнес-архитектурой, а только анализирует существующую архитектуру, описывает её. Этого недостаточно для управления.
Вопросы и ответы
Вопрос:
Где можно применять TOGAF в реальной практике?
Ответ:
TOGAF может быть применён в любой организации, как коммерческой, так и некоммерческой. Другое дело, что до его использования компания должна «дорасти».
Вопрос:
Что должен знать и понимать о бизнес-архитектуре системный аналитик, product owner?
Ответ:
Если речь про заказную разработку, то product owner и аналитик должны знать о бизнес-архитектуре заказчика всё, потому что иначе этот программный продукт будет бесполезен.
Если речь о продуктовой разработке, то здесь они должны спроектировать и задокументировать ту бизнес-архитектуру, которую будут цифровизировать в рамках решения. Описать, что решение предоставляет сервисы application data services для бизнес-сервисов на уровне этой бизнес-архитектуры, и потребляет некие технологические сервисы. Когда наступит этап продажи продукта, то можно будет понять, насколько та БА, которая легла как модель для формализации требований к продукту, отличается от БА клиента, и можно ли адаптировать продукт под клиента. Если у вас нет этой БА, то в процессе реального внедрения будет много проблем.
Если речь о продуктовой разработке, то здесь они должны спроектировать и задокументировать ту бизнес-архитектуру, которую будут цифровизировать в рамках решения. Описать, что решение предоставляет сервисы application data services для бизнес-сервисов на уровне этой бизнес-архитектуры, и потребляет некие технологические сервисы. Когда наступит этап продажи продукта, то можно будет понять, насколько та БА, которая легла как модель для формализации требований к продукту, отличается от БА клиента, и можно ли адаптировать продукт под клиента. Если у вас нет этой БА, то в процессе реального внедрения будет много проблем.
Вопрос:
Чем БА отличается от ИТ-архитектуры?
Ответ:
БА — это совокупность социальных компонентов, и она содержит в себе неотъемлемый компонент — иррациональные взаимодействия, за который отвечает HR. ИТ-архитектура — это техническая составляющая, и если всё формализовано, то работать она будет именно так, как её формализовали. В БА, если не поставлена работа с иррациональным взаимодействиями, то работать она будет непредсказуемо, невзирая на формализацию.
Вопрос:
Что первично, БА или ИТ-архитектура?
Ответ:
Однозначно, БА первична, потому что она генерирует денежный поток. При этом надо помнить, что в наше время БА без ИТ-архитектуры просто не жизнеспособна.
Александр Кварцхава
Директор по управлению IT и корпоративной архитектурой
Менеджер, корпоративный архитектор, архитектор 1С, 10 лет в IT.
Эксперт по конфигурации 1С ERP и смежным решениям.
Прошёл путь от линейного аналитика до корпоративного архитектора и IT директора.
Эксперт по конфигурации 1С ERP и смежным решениям.
Прошёл путь от линейного аналитика до корпоративного архитектора и IT директора.
