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

1. Подготовительный этап

Выбор референсной модели

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

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

Мы рекомендуем использовать Референсную модель бизнес-архитектуры Deep Vision.

Определение набора точек зрения

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

Точки зрения позволяют бизнес-архитекторам продемонстрировать решение задач и проблем заинтересованных сторон в рамках бизнес-архитектуры.

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

Выбор подходов и инструментов

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

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

Подготовка такого рода позволяет существенно упростить процесс создания бизнес-архитектуры.

Формирование подхода к моделированию

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

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

В совокупности вышеуказанные действия определяют подход к моделированию бизнес-архитектуры.

Подготовка перечня каталогов

Каталог – перечень и описание однотипных элементов бизнес-архитектуры. Например: каталог организационных единиц, каталог бизнес-процессов, каталог ИТ сервисов и т.д.

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

Каталоги имеют свою иерархию, то есть они содержат описание классов, подклассов и конкретных элементов. Например: каталог организационных единиц, каталог должностей, каталог ролей.

Каталоги являются исходным материалом для разработки моделей и матриц.

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

Выбор набора матриц

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

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

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

Определение необходимых диаграмм

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

Диаграммы отражают одну или несколько точек зрения на бизнес в соответствии с требованиями заинтересованных сторон.

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

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

Сбор бизнес-планов

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

Формирование сценариев бизнес-архитектуры

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

Подготовка базы знаний бизнес-архитектуры

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

На данном этапе необходимо подготовить базу знаний для дальнейшего наполнения.

Выявление требований

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

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

Требования должны:

• Ориентироваться на бизнес 
  
• Охватывать требования к информации, данным, функциям приложений и сервисов, а также к технологиям, которые применяет бизнес для реализации процессов 
  
• Содержать в себе критерии оценки соответствия решений, заложенных в целевой архитектуре, требованиям 
  

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

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

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

2. Описание текущей архитектуры

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

Помимо этого объем и степень детализации зависит еще от двух факторов:

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

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

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

Бизнес-архитектура

Бизнес-архитектура: суть и содержание

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

Читать

3. Разработка целевой архитектуры

Следующим шагом после описания существующей является разработка целевой бизнес-архитектуры.

Объем описания и степень детализации определяются на основании:

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

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

4. Верификация и анализ разрывов

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

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

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

5. Формирование дорожной карты перехода

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

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

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

6. Оценка воздействия бизнес-архитектуры

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

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

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

7. Проверка заинтересованными сторонами

До данного этапа бизнес-архитектура прошла все необходимые проверки. Осталось получить удостоверение заинтересованных сторон в том, что получено именно то, что нужно.

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

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

Согласование должно быть закреплено в Положении о бизнес-архитектуре.

8. Наполнение репозитория и базы знаний

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

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

9. Сборка итогового документа

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

Также необходимо убедиться в том, что:

• Все решения, связанные с представлением элементов архитектуры, а также решения, которые идут вразрез с изначальными целями и задачами создания бизнес-архитектуры, нашли свое отражение в документе.  
  
• Разделы документа включают в себя: 
  

     o Подробное описание бизнес-функций и процессов 

     o Описание расположений, рабочих мест, сервисов, технологий и людей, связанных с ключевыми процессами 

     o Описание потребности функций и бизнес-процессов в информации 

     o Стандарты, правила, руководства, которые описывают методы реализации функций и бизнес-процессов 

     o Должностные инструкции 

     o Описание механизмов контроля и отчетности 

• Модели, графики и отчеты, демонстрирующие основные точки зрения на бизнес-архитектуру 

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

На этом я завершаю обзор процесса разработки бизнес-архитектуры.

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