Нотации моделирования процессной архитектуры

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

Моделирование системы процессов решает ряд стратегических задач:

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

Вместе с тем выход на уровень системы процессов предполагает освоение новых компетенций и новых инструментов.

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

В части инструментов возникает необходимость выбора программного продукта и нотации моделирования. Если на уровне отдельного процесса стандарт и де-юре, и де-факто — это BPMN 2.0 [1], то выбор нотации для моделирования процессной архитектуры не столь очевиден. Нотация BPMN для работы с системой процессов непригодна — в ее палитре нет значка для изображения группы процессов.

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

Моделирование бизнес-процессов, бизнес-функций и бизнес-способностей

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

Не вдаваясь в подробности, надо пояснить, почему такая расширительная трактовка не корректна. Дело в том, что с понятиями всегда связаны определенные методы, и когда речь идет об управлении проектами, возникает иерархическая структура работ и диаграмма Ганта, а говоря о процессах, представляется блок-схема или диаграмма в нотации BPMN (рис. 1).

Рис. 1. Пример диаграммы бизнес-процесса в нотации BPMN

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

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

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

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

Рис. 2. Некорректное использование нотации BPMN для моделирования функций подразделения

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

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

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

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

Рис. 3. Пример процессной иерархии

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

Требования к нотации моделирования процессной архитектуры

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

1. Возможность моделировать процессную иерархию. Как только число моделей процессов в организации начинает исчисляться десятками, наступает хаос — множество разрозненных процессов уже невозможно охватить взглядом, в каких-то областях они начинают пересекаться, а какие-то области деятельности остаются непокрытыми. Нотация должна позволять структурировать деятельность компании через моделирование иерархии групп процессов и конкретных процессов.
2. Возможность моделировать взаимодействие между процессами. То, что с точки зрения бизнеса представляется единым процессом, зачастую моделируется несколькими процессами, протекающими асинхронно (каждый выполняется в своем ритме). Например, работу с кандидатом при найме персонала следует моделировать отдельным, хотя и связанным с процессом найма, процессом BPMN [3]. Нотация должна позволять моделировать межпроцессное взаимодействие.
3. Простота и наглядность. Нотация должна позволять создавать визуально привлекательные диаграммы с ясно прослеживаемой логикой. Запутанные и неряшливые диаграммы не только сложно воспринимать — они не вызывают доверия и, как следствие, желания ими пользоваться, что обесценивает работу по их созданию. Ключевая техника — иерархическая декомпозиция модели. Иногда встречаются диаграммы из склеенных листов бумаги размером 2×3 метра — это тупиковый путь. Чтобы не утонуть в деталях и охватить взглядом картину в целом, необходимо выделять уровни абстракции, оформляя их в виде групп процессов и на отдельном листе размещая каждую отдельную диаграмму. Нотация должна позволять декомпозировать процессную иерархию на несколько диаграмм, каждая из которых помещается на одном экране монитора и может быть выведена на печать формата А4 так, чтобы надписи при этом оставались читаемыми.
4. Интуитивная понятность. Бизнес (участники процессов и их руководители, владельцы и менеджеры процессов и проч.) ожидает от графической диаграммы процесса, что она будет понятна на интуитивном уровне — без специального обучения и с минимальными пояснениями, а в идеале — вообще без дополнительных пояснений. Тут следует сделать несколько оговорок: говоря об интуитивной понятности, имеется в виду, во‑первых, чтение диаграммы; во‑вторых, диаграммы грамотно составленной (нечитаемую диаграмму можно создать в любой нотации); в‑третьих, диаграммы процесса, который в той или иной степени знаком пользователю (разобраться с полностью незнакомым процессом сложнее). Перед автором диаграммы (процессным аналитиком, процессным архитектором) стоит более сложная задача — сделать диаграмму корректной, понятной и эстетически привлекательной, а здесь без обучения и практики уже не обойтись — между умением читать диаграмму и умением ее создать лежит пропасть компетенций и опыта. Требование интуитивной понятности не менее важно, чем функциональные требования, — именно бизнес, а не процессные архитекторы и не процессные аналитики, должен рассматриваться в качестве основного пользователя нотации. К сожалению, на практике часто приходится видеть «диаграмму для аналитиков», «диаграмму для программистов» и «архитектуру для архитекторов». Но если диаграмму процесса понимает только ИТ-специалист и если для того, чтобы узнать, как реально работает процесс, надо обращаться к ИТ, то значит, управляет процессом не бизнес, а ИТ.

Обзор процессных нотаций

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

IDEF0

Нотация IDEF0 (Icam DEFinition for Function Modeling — «методология функционального моделирования») была предложена в начале 1980-х годов как часть методологии структурного анализа и проектирования SADT (Structured Analysis and Design Technique) и принята как стандарт Национального института по стандартам и технологиям США (NIST). Изначально IDEF0 была нотацией моделирования функций системы и с этой задачей хорошо справляется, например, с помощью IDEF0 удобно описывать регламент взаимодействия подразделений, которые можно рассматривать как высокоуровневые бизнес-функции. Впоследствии IDEF0 стали применять и для моделирования процессов, но с этой задачей нотация справляется уже хуже — в ней нет развилок для описания вариантов протекания процесса (рис. 4).

Рис. 4. Пример диаграммы процесса в нотации IDEF0. Источник: technology.snauka.ru/2016/12/11467

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

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

Простота и наглядность. Нотация включает один элемент-сущность (функция) и стрелки для моделирования входов (input), выходов (output), управления (control) и механизмов (mechanism). Наглядность диаграмм IDEF0 страдает из-за того, что объекты/данные не выделены в качестве самостоятельных элементов, а моделируются надписями на стрелках. Также не способствует наглядности одинаковый вид стрелок — чтобы выяснить, что означает данная стрелка, необходимо отследить ее до функции-получателя: если стрелка соединяется с функцией слева, то это вход, если сверху — управление, а если снизу, то механизм. Требование соединять стрелки выходов строго с правой, а входов — с левой стороны функции может приводить к запутанным диаграммам. Жесткое ограничение на количество функций на одном уровне (от трех до пяти) может приводить к чрезмерной глубине процессной иерархии, что также не способствует наглядности.

Интуитивная понятность. Хотя нотация IDEF0 интуитивно понятна бизнес-пользователям, интуитивная трактовка диаграммы не всегда совпадает с ее истинным значением. Так, стрелки, соединяющие функции по входам-выходам, на интуитивном уровне воспринимаются как последовательность действий в блок-схеме, но связь по входам-выходам в общем случае не предполагает строго последовательного выполнения [4]. Затруднения может вызывать семантика стрелок, которая зависит от того, с какой стороны они соединяются с функцией. Не очевидно также понятие механизма, которое в IDEF0 включает инструменты и людей (работников).

DFD

Нотация DFD (Data Flow Diagram — «диаграмма потоков данных») была предложена в середине 1970-х годов как средство моделирования потоков данных в системах и процессах (рис. 5).

Рис. 5. Процессы производственного планирования в нотации DFD

Как и IDEF0, нотация DFD плохо подходит для моделирования потока работ в процессе — нет ни потоков управления, ни развилок. Но моделировать процессную архитектуру в DFD удобно. Примечательно, что у нотации есть два варианта визуального отображения элементов (таблица 1), при этом семантика элементов одна и та же, несмотря на разный внешний вид [5].

Моделирование процессной иерархии. DFD поддерживает иерархическую декомпозицию процессов.

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

Простота и наглядность. Нотация достаточно проста — в ней только три элемента-сущности (процесс/система, внешняя сущность, хранилище данных) и стрелка для отображения потоков данных. Нотация не накладывает жестких ограничений на количество элементов на диаграмме и на то, с какой стороны стрелки должны соединяться с объектами, благодаря этому DFD позволяет разместить на одной диаграмме больше элементов и в более наглядном виде.

Интуитивная понятность. Бизнес-пользователями нотация DFD воспринимается легко, но часто неправильно — затруднения вызывает интерпретация стрелок: интуитивно бизнес-пользователи воспринимают их как входы-выходы процесса, тогда как в действительности они показывают чтение-запись данных. Здесь проявляется различие между заинтересованными сторонами. Бизнес в первую очередь интересует, как продукт (выход) одного процесса становится ресурсом (входом) другого, в итоге формируя цепочку переделов от сырья через полуфабрикаты до готовой продукции. ИТ-специалистов интересуют потоки данных, которые они закладывают в архитектуру разрабатываемых систем. Можно констатировать, что нотация DFD больше ориентирована на потребности ИТ, а не бизнеса.

BPMN

Нотация BPMN (Business Process Model and Notation — «нотация и модель бизнес-процесса») появилась в 2002 году в результате усилий консорциума производителей программного обеспечения BPMI (Business Process Management Initiative). В 2011 году консорциум OMG (Object Management Group) опубликовал версию 2.0, и с этого момента BPMN стали поддерживать все ведущие поставщики программного обеспечения для моделирования бизнес-процессов — стандарт ISO/IEC 19510:2013.

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

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

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

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

VAD

Нотация VAD (Value-Added Chain Diagram, диаграмма цепочки создания ценности) — составная часть методологии ARIS (Architecture of Integrated Information Systems) и наиболее полно реализована в одноименном ПО. Ее основное назначение — показать функции, непосредственно участвующие в создании ценности для потребителя [6].

Рис. 6. Пример диаграммы VAD. Источник: ARIS Method Manual

На практике VAD (рис. 6) используется для моделирования и процессной, и функциональной иерархий.

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

Моделирование межпроцессного взаимодействия. На диаграмме VAD стрелки, идущие слева направо, показывают взаимодействие процессов в рамках цепочки создания ценности.

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

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

ArchiMate

Нотация ArchiMate (Architecture-Animate, визуальное моделирование архитектуры предприятия) позиционируется в качестве открытого стандарта моделирования архитектуры, включая бизнес-процессы, организационную структуру, потоки информации, ИТ-приложения и ИТ-инфраструктуру. В отличие от BPMN, «открытый» не означает бесплатный — коммерческое использование ArchiMate требует лицензирования. Хронологически нотация появилась и развивалась параллельно с BPMN — начало разработки 2002 год, выход версии 1.0 под эгидой The Open Group в 2009 году, а в 2012 году опубликована версия 2.Но в отличие от BPMN, остановившемся на версии 2.0.2, стандарт ArchiMate продолжает развиваться — текущая версия 3.2 выпущена в 2022 году.

Структура ArchiMate — двумерная матрица: аспекты (пассивные элементы, активные элементы, поведение, целеполагание) и слои (от стратегии до физической ИТ-инфраструктуры и планирования внедрения). Структура ArchiMate схожа со структурой TOGAF — оба стандарта разрабатывает одна организация The Open Group, стремящаяся интегрировать TOGAF ADM (Architecture Development Method) в качестве методологии разработки архитектуры предприятия, а ArchiMate в качестве инструмента.

Рис. 7. ArchiMate Core Framework — ключевые аспекты и элементы. Источник: visual-paradigm.com/guide/archimate/what-is-archimate

К ключевым аспектам в ArchiMate (рис. 7) относятся активные компоненты (бизнес-роли, ИТ-приложения, физические устройства — «субъекты» архитектуры), пассивные компоненты (информация, объекты данных, физические объекты) и поведение (процессы, функции, события, сервисы).

Идея универсальной нотации, покрывающей все задачи моделирования «вширь» и «вглубь», достаточно привлекательна, однако практики сходятся во мнении, что ArchiMate призвана не столько заменить прочие стандарты и подходы, сколько их дополнить и интегрировать [7]. Существующие специализированные нотации и методы моделирования различных аспектов позволяют отразить их более детально и в то же время более наглядно. Уникальная роль ArchiMate заключается в том, чтобы показать зависимости между различным аспектами и слоями, дав обзорное представление архитектуры предприятия.

Моделирование процессной иерархии. ArchiMate поддерживает как иерархическую декомпозицию диаграмм, так и вложенность процессов на одной диаграмме (рис. 8). Визуально процессы и группы процессов в ArchiMate не различаются.

Рис. 8. ArchiMate Process Architecture View — Диаграмма процессной архитектуры. Источник: help.bizzdesign.com/articles/#!horizzon-help/modeling-a-process-architecture-view

Моделирование межпроцессного взаимодействия. ArchiMate позволяет моделировать взаимодействие между процессами посредством событий и данных (рис. 9).

Рис. 9. ArchiMate Business Process Cooperation — диаграмма межпроцессного взаимодействия. Источник: online.visual-paradigm.com/ru/diagrams/templates/ archimate-diagram/business-process-co-operation/

Простота и наглядность. Некоторые источники утверждают, что BPMN и UML — нотации более тяжеловесные, чем ArchiMate: BPMN насчитывает свыше 250 элементов, а ArchiMate — лишь около 50 (в версии 3.1 это число выросло до 74). Такое сравнение представляется не вполне корректным, и хотя формально количество элементов в BPMN велико, получается оно путем умножения сравнительно небольшого количества базовых типов на количество модификаторов, которое также невелико. С другой стороны, ряд авторов считает, что количество элементов в ArchiMate «обескураживает» [8] — эта нотация для профессионалов, а не для дилетантов, и достаточно сказать, что только различных видов стрелок в ее палитре насчитывается 11.

Интуитивная понятность. Интуитивная понятность не относится к сильным сторонам ArchiMate. На рис. 10 и 11 показаны модели одного и того же процесса в ArchiMate и BPMN.

Рис. 10. Диаграмма процесса ввода данных в нотации ArchiMate

Рис. 11. Диаграмма процесса ввода данных в нотации BPMN. Источник: ea.rna.nl/2016/03/22/modelling-processes-in-archimate/

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

Итого

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

***

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

Требуется новая нотация моделирования процессной архитектуры, аккумулирующая опыт использования нотаций IDEF0, DFD, VAD.

Литература

1. Анатолий Белайчук. Главное преимущество BPMN // Открытые системы. СУБД.— 2012.— № 8. — С. 61–62. URL: https://www.osp.ru/os/2012/08/13019266 (дата обращения: 21.03.2026).

2. Белайчук А. А., Томорадзе И. В., Давыдов А. Г., Антонов И. А. Реабилитация линейно-функционального управления. Проблемы теории и практики управления, 2025. № 11 (406).

3. Сильвер Б. BPMN — метод и стиль. Zerde Publishing, 2025

4. Репин В. В. Про смысл стрелок в нотации IDEF0 и не только. 2025. URL: repin.guru/articles/pro-smysl-strelok-v-notatsii-idef0-i-ne-tolko (дата обращения: 22.03.2026).

5. What is a Data Flow Diagram (DFD)? URL: ibm.com/think/topics/data-flow-diagram (дата обращения: 21.03.2026).

6. ARIS Method Manual, October 2025. docs.aris.com/latest/yaa-method-guide/en/Method-Manual.pdf (дата обращения: 21.03.2026).

7. How to Combine ArchiMate With Industry Standards for Better EA. URL: bizzdesign.com/blog/how-combine-archimater-industry-standards-better-ea, 2025 (дата обращения: 21.03.2026).

8. Comprehensive Guide: ArchiMate vs. BPMN vs. UML, 2025. URL: www.archimetric.com/comprehensive-guide-archimate-vs-bpmn-vs-uml/ (дата обращения: 21.03.2026).

Анатолий Белайчук (bell@b-k.ru) — президент Ассоциации профессионалов управления бизнес-процессами (ABPMP Russian Chapter); Илья Томорадзе (ilya@ranepa.ru) — доцент, РАНХиГС при Президенте России (Москва).