Цепочка создания ценности (Value-Added Chain, VAD) и событийная цепочка процессов (Event-driven Process Chain, EPC) — две нотации семейства ARIS для описания деятельности на разных уровнях детализации. VAD фиксирует укрупнённые функции, создающие ценность; EPC раскрывает операционную логику: события, ветвления, исполнителей и данные. Вместе они дают двухуровневый каркас от функциональной карты до регламента — в связке с 03.04.01 BPMN 2.0 - введение и основы и 03.04.02 Диаграмма потоков данных (DFD).

1. Суть темы

VAD и цепочка ценности Портера — не одно и то же

Классическая цепочка ценности Майкла Портера (1985) — стратегический инструмент: первичные и поддерживающие виды деятельности, маржа, конкурентное преимущество. VAD в ARIS — нотация моделирования: линейная (или слабо разветвлённая) последовательность функций с связями предшествования, без событий, исполнителей и логических операторов. Идея «функции добавляют ценность» родственна Портеру, но layout, терминология и цель другие: VAD не копирует схему primary/support activities и не показывает margin — это вход в репозиторий ARIS для декомпозиции в EPC или BPMN.

Не путайте VAD с Value Stream Mapping (VSM) из Lean: VSM измеряет поток материала и информации во времени, выявляет потери; VAD — статическая функциональная карта без тайминга. Подробнее о бережливом мышлении — 01.05 Теория ограничений и бережливое мышление.

EPC как операционный слой

EPC (Event-driven Process Chain) разработана в рамках ARIS (Architecture of Integrated Information Systems) Августа-Вильгельма Шеера. Процесс — строгое чередование событий и функций: событие описывает достигнутое состояние, функция — активное действие. Отличие от BPMN не в «важности событий» (в BPMN 2.0 события — полноценные элементы), а в обязательном паттерне event→function, привязке org unit и information object на одной диаграмме и исторической связке с SAP/ARIS-репозиториями. BPMN сильнее там, где нужна исполняемая семантика, pools/lanes и экосистема движков (Camunda и др.).

Два уровня одной системы моделирования

УровеньНотацияВопрос
Укрупнённый (value-added chain)VADКакие функции создают ценность и в каком порядке?
ОперационныйEPCКак функция выполняется: события, ветвления, роли, данные?

VAD в ARIS — функциональная карта цепочки, а не стратегическая модель компании в смысле Porter или ArchiMate. На практике VAD строят первым; каждая функция VAD декомпозируется в отдельную EPC-диаграмму. В ARIS типовой паттерн: функция на VAD = корневая функция связанной EPC-модели или интерфейс процесса (Process Interface), указывающий на подчинённую EPC. Прослеживаемость от функции VAD до требований оформляют через 02.03.04 Трассировка требований (концепция) и 10.01.15 Шаблон матрицы трассировки — здесь достаточно зафиксировать связь «функция VAD → EPC → функциональное требование».

2. Ключевые понятия

2.1 Элементы VAD

  • Функция (Function) — прямоугольник со скруглёнными углами; имя — отглагольное существительное или глагол («Снабжение», «Сборка»). Функции выстраиваются слева направо.
  • Связь предшествования — стрелка логической зависимости «выход одной функции — вход для следующей». Не показывает передачу данных — только порядок в цепочке.
  • Группы — иногда функции делят на «Основные» и «Поддерживающие» (HR, IT, финансы); на диаграмме поддерживающие часто размещают сверху или снизу с ассоциативными связями к основным.

Ветвление в VAD: в классической VAD нет AND/OR/XOR. Допустимо слабое разветвление — несколько функций могут получать связь предшествования от одной (fork) или сходиться в одну (join), но без условий на потоках: это не альтернативы, а параллельные или convergent ветки на уровне «областей деятельности». Условная логика переносится на EPC.

graph LR
    A[Маркетинг и привлечение] --> B[Оформление заказа] --> C[Обработка и сборка] --> D[Доставка] --> E[Послепродажное обслуживание]

Поддерживающие функции: IT-инфраструктура, управление персоналом, финансовый учёт.

2.2 Элементы EPC

ЭлементОбозначениеОписание
Событие (Event)ШестиугольникПассивное состояние до или после функции. Имя: существительное + глагол в прошедшем времени («Заказ поступил», «Счёт выставлен»).
Функция (Function)Скруглённый прямоугольникАктивное действие. Имя: глагол + существительное («Проверить наличие», «Сформировать счёт»).
Логический оператор (Connector)Кружок ∧ / ∨ / ⊻Ветвление и слияние потоков управления.
Организационная единица (Org Unit)Эллипс с вертикальной чертойИсполнитель (должность, отдел); связывается с функцией.
Информационный объект (Information Object)Прямоугольник с загнутым угломДанные/документ, которые функция потребляет или создаёт. Имена согласуют с 03.03.03 Словарь данных (описание) и сущностями 03.03.01 ER-диаграммы (сущность-связь).
Интерфейс процесса (Process Interface)Малый прямоугольник со стрелкойСсылка на другую EPC-диаграмму; используется, когда на одной схеме >15 функций или ветвление выносится в подпроцесс.
Поток управленияСплошная стрелкаХронологический порядок между событиями, функциями и операторами.

Золотое правило EPC: события и функции строго чередуются. Две функции или два события подряд — ошибка (кроме случаев с оператором между ними). Каждая функция инициируется событием(ями) и порождает событие(я).

2.3 Логические операторы: split и join

ОператорSplit (разветвление)Join (слияние)
AND (∧)Активируются все исходящие ветвиПродолжение после всех входящих ветвей
OR (∨), inclusiveАктивируются одна или несколько исходящих ветвейДостаточно хотя бы одной завершённой входящей ветви
XOR (⊻)Активируется ровно одна исходящая ветвьПродолжение после ровно одной входящей ветви

На split XOR/OR подписывайте условия на каждом исходящем потоке. На join XOR в типичной трактовке ARIS означает «первый пришедший выигрывает» (эксклюзивное слияние); OR — «достаточно любого пути»; AND — синхронизация всех параллельных веток. Семантику join задаёт метамодель инструмента, а не только бизнес-правило: join-XOR в EPC не всегда однозначно соответствует exclusive merge в BPMN. При переносе в Camunda или другой движок сверяйте поведение веток с документацией инструмента, иначе получите скрытые расхождения в orchestration.

Типичная ошибка: поставить XOR на split и OR на join «для симметрии» — тип join должен соответствовать бизнес-правилу слияния, а не зеркалировать split автоматически.

2.4 Пример EPC (эмуляция в Mermaid)

Mermaid не поддерживает нативную EPC; шестиугольники заменены скруглёнными прямоугольниками, операторы — ромбами.

flowchart TD
    E1([Заказ получен]) --> F1[Проверить наличие]
    F1 --> E2([Наличие проверено])
    E2 --> XOR1{ }
    XOR1 -->|Товар отсутствует| F2[Уведомить клиента]
    XOR1 -->|Товар в наличии| F3[Зарезервировать товар]
    F2 --> E3([Клиент уведомлён])
    F3 --> E4([Товар зарезервирован])
    E3 --> XOR2{ }
    E4 --> XOR2
    XOR2 --> F4[Выставить счёт]
    F4 --> E5([Счёт выставлен])
    E5 --> AND1{ }
    AND1 --> F5[Принять оплату]
    AND1 --> F6[Упаковать заказ]
    F5 --> E6([Оплата принята])
    F6 --> E7([Заказ упакован])
    E6 --> AND2{ }
    E7 --> AND2
    AND2 --> F7[Передать в доставку]
    F7 --> E8([Заказ передан в доставку])

    F1 ---|исполнитель| ORG1[Менеджер по продажам]
    F4 ---|использует| DATA1[Данные клиента]
    F7 --> PI[[Интерфейс: Процесс доставки]]

Схема иллюстрирует синтаксис EPC и join XOR2: альтернативные ветви «отсутствует / в наличии» сходятся перед общей функцией. В реальном процессе ветка «товар отсутствует» чаще завершается событием «Заказ отменён» или альтернативным сценарием — без резерва и выставления счёта; merge здесь учебный, не эталон бизнес-логики. Интерфейс процесса в конце выносит «Доставку» на отдельную EPC — по правилу 5–15 функций на диаграмму.

2.5 Сравнение VAD, EPC и соседних нотаций

ХарактеристикаVADEPCIDEF0DFD
ФокусЦепочка функцийСобытийный поток работICOM одной функции и декомпозицияПотоки данных между процессами
УровеньУкрупнённый (без времени и событий)ОперационныйФункциональный (без времени)Информационный
ВетвлениеТолько слабое, без условийAND/OR/XORFork/join на дугах ICOMНет
ИсполнительНе показываетсяOrg UnitMechanism (снизу блока)Не показывается
ДанныеНе показываютсяInformation ObjectInput/OutputПотоки и хранилища

IDEF0 декомпозирует одну функцию с ICOM на периметре — см. 03.04.03 IDEF0 и его применение. DFD показывает движение данных между процессами: information object в EPC соответствует потоку или сущности, которую процесс потребляет/производит, но не заменяет DFD — дополняет организационно-событийный взгляд.

Критерий выбора первой нотации: нужен порядок функций без времени и событий → VAD; нужен event-driven регламент с ролями → EPC; нужен ICOM одного блока и иерархическая декомпозиция → IDEF0; нужна карта движения данных между процессами → DFD. Нотации дополняют друг друга, а не заменяют.

3. Как применяется в работе аналитика

Когда нужны VAD и EPC

Выбирайте пару VAD + EPC, если:

  • корпоративный стандарт — ARIS, Signavio или legacy-документация в SAP Solution Manager (в новых контурах документирование часто смещено к BPMN и Signavio — уточняйте у заказчика);
  • нужен регламент с явным чередованием «состояние → действие» и привязкой к org unit;
  • проект ERP/SAP, где EPC исторически связана с business blueprint.

VAD на ранней фазе помогает согласовать скоуп с бизнесом — одно-два предложения о границах проекта, детальная методика — в 02.01.04 Определение границ решения (Scope Modelling). EPC детализирует 02.03.03 Спецификация требований (SRS, Use Case, User Story) и 02.03.01 Классификация требований (БТ, ФТ, НФТ) на уровне функций и information objects.

Рабочий процесс

  1. VAD — 5–12 функций цепочки; согласование с руководством и 02.01.01 Определение бизнес-проблем и возможностей.
  2. Декомпозиция — для каждой функции VAD создайте EPC в ARIS: assign связывает функцию VAD с моделью EPC в репозитории, decompose открывает подчинённую диаграмму; функция VAD = корень EPC или process interface с типом связи «assignment/decomposition».
  3. Детализация EPC — события, ветвления, org units, information objects; имена данных — из 03.03.03 Словарь данных (описание).
  4. Трассировка — функция VAD → EPC-диаграмма → функциональное требование (02.03.04 Трассировка требований (концепция)).
  5. При переходе к исполнению — точечный перенос логики в BPMN (03.04.01 BPMN 2.0 - введение и основы, 06.02.04 Работа с Camunda); оформляйте to-be по 10.01.08 Шаблон сквозной фичи (BPMN-процесс).

Признаки, что пора переходить с EPC на BPMN (to-be): процесс нужно исполнять в движке (orchestration, SLA-таймеры); шаги выполняют системы, а не только org unit; между шагами — сообщения, очереди, API; регламент as-is зафиксирован в EPC, а to-be проектируется под Camunda или аналог.

Мост к проектированию ИС

Элементы EPC напрямую стыкуются с артефактами системного анализа без дублирования соседних статей:

Операционный слой можно также описать 03.02.02 Диаграмма деятельности (Activity Diagram), если заказчик не использует ARIS — но трассировка VAD → EPC → BPMN остаётся типовым enterprise-паттерном.

VAD vs EPC vs BPMN — критерии выбора

КритерийEPCBPMN
ИсполняемостьНет нативной семантики для движкаДа (BPMN 2.0, Camunda и др.)
Чередование event/functionОбязательное правило нотацииГибче (tasks, gateways, events)
Org unit на диаграммеВстроенный элементPools/lanes — для ролей и систем; org unit на EPC достаточен для регламента, для сквозной автоматизации чаще нужны lanes
ЭкосистемаSAP, ARIS, SignavioМеждународный стандарт, широкая поддержка

Гибрид: VAD (укрупнённая карта) → EPC (регламент as-is, org/data) → BPMN (to-be и исполнение). Не дублируйте одну и ту же логику в трёх нотациях без явной цели артефакта.

Инструменты

ИнструментРоль
ARIS (Software AG)Полная VAD/EPC, репозиторий, декомпозиция
Signavio Process ManagerEPC (расширение), VAD, коллаборация; интеграция с SAP
SAP Solution ManagerSolution Documentation; EPC в legacy-контурах, BPMN/Signavio в новых
Microsoft VisioШаблоны EPC/VAD (часто в связке с ARIS); без репозиторной декомпозиции
draw.io / LucidchartEPC/VAD — ограниченно: нет нативной семантики ARIS, assign/decompose и проверки правил; годятся для разовых схем и презентаций

Сравнение платформ моделирования — 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io); Camunda Modeler ориентирован на BPMN, для полноценной VAD/EPC — ARIS или Signavio.

Чеклист качества EPC

  • Диаграмма начинается и заканчивается событием (или process interface с согласованными граничными событиями).
  • Чередование event ↔ function без пропусков.
  • Тип join согласован с типом split, бизнес-правилом слияния и метамоделью инструмента.
  • Условия подписаны на всех исходящих потоках XOR/OR.
  • 5–15 функций на диаграмму; избыточное — в process interface.
  • Org units привязаны к функциям, не «висят» без связи.
  • Information objects названы по 03.03.03 Словарь данных (описание).
  • Нет «осиротевших» веток без выхода в событие или интерфейс.
  • Walkthrough по happy path и dead branch (ветка «товар отсутствует» и аналоги) — см. 08.03 Тестирование требований (статическое тестирование).

Рецензирование моделей — 08.04 Рецензирование и инспекции (техники Фейгана).

4. Типовые ошибки и ограничения

  • Смешение Портера и VAD — перенос layout primary/support activities на VAD и ожидание margin-анализа. VAD — функциональная карта ARIS, не стратегическая матрица Портера.
  • Смешение VAD и VSM — попытка измерить lead time на VAD. Для потока создания ценности во времени — Lean/VSM (01.05 Теория ограничений и бережливое мышление).
  • «EPC про события, BPMN про поток» — упрощение; критерии выбора — в таблице §3 «VAD vs EPC vs BPMN», а не в противопоставлении «важности» элементов.
  • Учебный merge за эталон процесса — схлопывание веток «отсутствует / в наличии» в одну функцию без проверки бизнес-правила (см. §2.4).
  • Нарушение именования событий — «Результат проверки» вместо «Наличие проверено» ломает согласованность с регламентом и правилами нотации.
  • Несогласованный join — XOR-split и OR-join «по умолчанию»; ветки зависают или сливаются дважды; при миграции в BPMN поведение расходится с ожиданием.
  • Перегруженная EPC — 30+ функций на одном листе; нет process interface при декомпозиции из VAD.
  • Дублирование IDEF0/BPMN — моделировать ту же функцию в VAD, IDEF0 и BPMN без разных целей артефакта.
  • Устаревший совет «только EPC в SAP» — в актуальных ландшафтах документирование часто через Signavio/BPMN; EPC остаётся в legacy blueprint и ARIS-репозиториях.

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

  • Porter, M. (1985). Competitive Advantage: Creating and Sustaining Superior Performance. Free Press. — Классическая цепочка ценности (стратегический контекст, не тождественна ARIS VAD).
  • Scheer, A.-W. (1999). ARIS — Business Process Modeling. 3rd ed. Springer. — Методология ARIS, VAD и EPC.
  • Keller, G., Nüttgens, M., Scheer, A.-W. (1992). Semantik von ereignisgesteuerten Prozessketten. IWi, Universität des Saarlandes. — Формализация EPC.
  • Silver, B. (2012). BPMN Method and Style. — Сравнение EPC и BPMN, рекомендации по выбору нотации.

Курсы и документация инструментов

Статьи