Введение: проблема реактивного проектирования

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

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

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

Дополнительно хотел бы обратить внимание на Профессиональный стандарт 07.007 «Специалист по процессному управлению», в рамках которого существует роль «Процессный архитектор» (7-ой уровень квалификации). На мой взгляд, именно в рамках процессной архитектуры данная роль является синонимом роли «Бизнес-аналитик» (Профессиональный стандарт 08.037), если говорить про фазу проектирования ИТ-решений, в рамках которой они в т.ч. существуют.

Схемы в статье приведены в нотации ArchiMate.

Данная статья в определённом смысле является продолжением статьи «Исполняем желания заказчика: бизнес-требования на автоматизацию и их связь с корпоративной архитектурой организации» https://habr.com/ru/articles/953794/

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

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

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

Бизнес-архитектура включает в себя следующие элементы:

Стратегия и цели:

• какие цели преследует компания;

• какие ключевые показатели эффективности (KPI) используются для измерения успеха;

• какие ограничения и принципы заданы для деятельности;

 Бизнес-способности (подробней можно узнать здесь https://habr.com/ru/articles/959556/):

• что компания умеет делать на высоком уровне абстракции;

• какие способности являются критичными для достижения стратегии;

• какие способности нужно развивать, а какие можно аутсорсить;

 Организационная структура:

• какие подразделения существуют;

• как они связаны между собой;

• какие роли и зоны ответственности определены;

 Процессная архитектура (именно в такой терминологии наименование не приводится, об этом ниже):

• как работа выполняется от начала до конца;

• как процессы связаны между собой сквозным образом;

• какие роли участвуют в процессах;

• какие бизнес-объекты создаются, изменяются и потребляются;

 Бизнес-объекты (глоссарий):

• какие сущности существуют в деятельности компании (клиент, заказ, продукт, счёт, договор);

• как эти сущности определены и как они связаны между собой;

• какая терминология является единой для всей компании;

 Потоки создания ценности:

• как ценность доставляется клиенту;

• какие шаги от первичного запроса до финального результата.

Что такое процессная архитектура

Процессная архитектура — это иерархическая, взаимосвязанная и сквозная модель деятельности компании. Она отвечает на вопрос «как именно компания делает то, что она делает».

Пример, как это может выглядеть с точки зрения структуры (вложенности) (взял отсюда: https://www.businessstudio.ru/articles/article/vnedrenie_business_studio_6_sozdanie_sistemnykh_sp/):

Ключевые характеристики процессной архитектуры:

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

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

• взаимосвязанность — процессы не изолированы. Один процесс передаёт результат другому. Процессы используют одни и те же бизнес-объекты. Изменение в одном процессе может повлиять на смежные процессы;

• сопровождаемость — модель живёт и обновляется, а не создаётся один раз «под проект». Процессная архитектура — это не документ, а постоянно актуализируемая модель;

• формализованность — процессы описаны в единой нотации (BPMN/CFFC/IDEF0/EPC/ArchiMate, причём возможны разные нотации на различном уровне декомпозиции, например ArchiMate/IDEF0 для верхнего уровня, BPMN для среднего и низкого), что позволяет однозначно интерпретировать их разными специалистами — от бизнес-аналитиков и архитекторов до разработчиков, тестировщиков и заказчиков;

Инструментом проектирования и сопровождения процессной архитектуры служат BPMS-системы (ARIS, Business Studio, Sparx EA, Software AG Alfabet или аналогичные), позволяющие вести процессное дерево как единую базу знаний, управлять версионностью и связывать объекты между собой.

Процессная архитектура как ключевой элемент бизнес-архитектуры

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

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

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

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

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

Процессная архитектура в TOGAF: от обязательного требования к управляемой практике

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

Более того, в Phase B (разработка бизнес-архитектуры) TOGAF предписывает создавать конкретные артефакты:

• каталог процессов — полный перечень процессов в иерархической структуре;

• диаграммы потоков процессов — с использованием BPMN как рекомендованной нотации;

• матрицы связей — между процессами, ролями, организационными единицами и бизнес-объектами.

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

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

• они постоянно и достаточно часто меняются;

• они описываются по-разному в разных проектах и разными людьми, и не сопровождаются централизованно;

• актуальность каждой отдельно взятой модели быстро теряется.

Формальное выполнение требований TOGAF (нарисовали каталог, сделали диаграммы, заполнили матрицы) без внедрения инструментов управления приводит к тому, что описание бизнес-процессов быстро превращается в «мёртвый документ». Оно есть, но им никто не пользуется.

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

Что даёт централизованное сопровождение единой модели процессной архитектуры:

• централизованное хранение — все процессы в одном месте, в единой нотации, с единой терминологией. Никаких разрозненных excel-файлов и картинок в confluence;

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

• связность объектов — в BPMS процессы связываются с ролями, бизнес-объектами, документами, KPI, системами. Изменение одного объекта автоматически показывает, на какие процессы оно повлияет;

• версионность и управление изменениями — каждое изменение процессной архитектуры фиксируется. Можно видеть, кто, когда и зачем изменил процесс. Можно откатиться к предыдущей версии;

• автоматизация работы аналитиков/архитекторов — никто не рисует процесс «с нуля» — они находят нужный процесс в репозитории, проверяют его актуальность, при необходимости вносят изменения (которые видны всем), и используют как основу для требований;

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

Таким образом, TOGAF задаёт правильное направление (процессная архитектура обязательна), а BPMS даёт практический инструмент, который делает эту архитектуру управляемой, актуальной и полезной для ежедневной работы аналитиков и архитекторов. Без BPMS процессная архитектура быстро превращается в формальность, с BPMS она становится рабочей средой, в которой живут и развиваются процессы компании.

Процессная архитектура как основа бизнес-требований на автоматизацию

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

Обычный для большинства компаний производственный процесс с реактивным проектированием, приведённый в самом начале статьи, помимо очевидной неоптимальности подхода, имеет ещё ряд проблем (особенно если аналитики разные на задачах):

• процессы не связаны между собой;

• в каждом проекте — своя терминология;

• нет единого источника правды;

• повторная работа из проекта в проект;

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

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

• владельцы процессов (сегментов в рамках общего процессного дерева)/технологи проактивно вносят изменения в процессную архитектуру в рамках своих границ: например, изучают проекты изменений НПА заранее, до вступления в силу изменений;

• в рамках полученного ЗНИ аналитик идентифицирует в процессном дереве уже существующий процесс (или его часть);

• определяет границы автоматизации — какой фрагмент процесса будет реализован в ИТ-системе, а какой останется «ручным»;

• берёт из процессной архитектуры описание шагов процесса, задействованные роли, бизнес-объекты (с уже согласованными определениями);

• формирует требования, где объект автоматизации — это готовый процесс (или его часть) из единой модели, согласовывает изменения в владельцем процесса;

• разработчик реализует требования, тестировщик контролирует качество (через тест-кейсы, соотнесённые с процессами);

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

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

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

Процессная архитектура как мост между бизнесом и ИТ

Процессная архитектура — это не просто инструмент описания деятельности. Это мост, который соединяет бизнес и ИТ.

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

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

• прикладная архитектура: какие системы и их компоненты/сервисы поддерживают выполнение шага процесса, какие интерфейсы они предоставляют, какие системные процессы запускаются;

• интеграционная архитектура: как данные передаются между системами для выполнения шага, какой протокол и метод используется, к каком формате передаются данные, кто является источником правды (мастером) для каждого поля или вида данных;

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

Когда все эти связи зафиксированы в процессной архитектуре, каждая задача на автоматизацию получает готовый контекст. Разработчик видит не просто «сделать форму ввода», а «на шаге 3 процесса «Оформление заказа» пользователь с ролью «Менеджер» вводит бизнес-объект «Заказ», который затем передаётся в систему CRM через интеграционный интерфейс».

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

Заключение

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

• структурирует бизнес-архитектуру в терминах TOGAF, делая её не набором деклараций, а рабочим инструментом;

• обеспечивает основу для бизнес-требований на автоматизацию, позволяя перейти от реактивного проектирования к проактивному;

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

Здесь я бы добавил ещё один пункт о том, что процессная архитектура позволяет пользоваться преимуществами цифрового двойника организации, но эта тема тянет на отдельную статью. Справочно — цифровой двойник (digital twin) — это виртуальная модель физического объекта или системы, которая позволяет моделировать, анализировать и прогнозировать поведение оригинала. Процессная архитектура — это цифровой двойник деятельности компании.

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

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

Мой ТГ-канал, если Вам интересна данная и около тема: https://t.me/arma_frame