От переводчика: сложность — интуитивно понятный, но трудно измеримый фактор в конкретных кейсах. Вот, например, что сложнее — самолет или лягушка? Правильный ответ конечно же лягушка. Потому что имея чертежи и технологии мы можем построить сколько угодно самолетов. Но у нас нет инструкции по изготовлению лягушек. — это отсылочка к Dave Snowden и его фреймворку Cynefin для анализа сложности.

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

Упрощение моделей

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

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

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

Для примера возьмем типовой кейс: расчет налога на прирост капитала от инвестиций в акции. Правила предельно простые:

1. Долгосрочный прирост капитала (long-term capital gains):

   - прибыль свыше 100 000 $ облагается по фиксированной ставке 10 %;

   - прибыль до 100 000 $ налогом не облагается.

2. Краткосрочный прирост капитала (short-term capital gains):

   - облагается по фиксированной ставке 15 %.

Новичок в моделировании вполне может нарисовать под это дело BPMN-диаграмму с кучей шлюзов и задач (как на первом рисунке).

Однако опытный аналитик упростит тот же кейс, используя DMN (Decision Model and Notation) — всю логику принятия решения он сведет в одну единственную задачу.

Анализ этих двух диаграмм четко показывает ключевые различия:

• Количество активностей
  Первая диаграмма содержит гораздо больше задач, включая инициализацию и задачи для человека.

• Пути принятия решений
  В ней появляется множество шлюзов, что значительно увеличивает сложность модели.

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

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

Почему сложность имеет значение

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

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

На пути к читаемым и поддерживаемым моделям

Практический способ снизить сложность — разбивать большие BPMN-диаграммы на небольшие, понятные подпроцессы или call activity. Цель не просто смоделировать поток, а дать ясную и понятную абстракцию. Будь то BPMN или CMMN, модели должны служить инструментом для эффективной коммуникации процессов, а не перегружать заинтересованных лиц.

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

Определение сложности

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

Например:

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

• Для SaaS-провайдера BPMN сложность может измеряться количеством операций ввода-вывода или вычислительно тяжелых задач.

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

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

С точки зрения этой концепции, типичными признаками сложности являются:

1. Множество путей выполнения
   Модели с большим количеством точек принятия решений и ветвлений.

2. Использование шлюзов
   Инклюзивные шлюзы (inclusive gateway) почти всегда сложнее эксклюзивных и параллельных, потому что из них может выходить сразу несколько потоков.

3. Глубокая вложенность
   Чем глубже вложены подпроцессы — тем сложнее.

4. Большое количество переменных
   Страховые процессы с сотнями переменных объективно сложнее, чем простой процесс согласования отпуска.

5. Декораторы CMMN
   Автовыполнение, сентинели с условиями, повторяющиеся планы и прочие декораторы резко повышают сложность.

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

7. И так далее
   В зависимости от контекста список можно продолжать.

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

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

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

В зависимости от того, какой аспект модели мы рассматриваем, все метрики можно разделить на четыре большие категории:

Метрики активностей

Эти метрики оценивают элементы в модели и дают моментальный снимок её внутреннего состава.

• Количество активностей (Number of Activities, NOA) — считает число активностей в BPMN-модели. Например, в «Процессе согласования» — 8 активностей: 6 пользовательских задач и 2 сервисных.

• Количество активностей, соединений и разветвлений (Number of Activities, Joins, and Splits, NOAJS) — расширяет NOA, включая потоки последовательности и шлюзы. Дает более полную картину. У «Процесса согласования» NOAJS = 21.

• Размер (CMMN) — аналог NOA, но для CMMN. Считает все элементы плана.
  Для «Кредитного кейса» размер равен 14.

• Взвешенная сложность (Complexity Weighted) — присваивает элементам разные веса в зависимости от их сложности. Например, сентинели с условиями получают больший вес, чем простые задачи процесса.

Метрики потока управления

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

• CFC(AND), (Control Flow Complexity for AND (Parallel) gateway) — сложность потока управления для параллельного шлюза (AND). Поведение всегда одинаковое: активируются все выходящие потоки. Поэтому CFC(AND) просто равен количеству параллельных шлюзов. В «Процессе согласования»: 1 + 1 = 2.

• CFC(XOR), (Control Flow Complexity for XOR (Exclusive) gateway) — сложность потока управления для эксклюзивного шлюза (XOR). По условию активируется только один поток, поэтому количество возможных путей равно количеству выходящих потоков (Fan Out). CFC(XOR) одного шлюза = Fan Out этого шлюза. В «Процессе согласования»: 1 + 2 + 2 + 2 + 2 + 2 + 2 + 3 + 1 = 17.

• CFC(OR), (Control Flow Complexity for OR (Inclusive) gateway) — сложность потока управления для инклюзивного шлюза (OR). Может активироваться любое подмножество выходящих потоков (кроме пустого). Количество возможных путей: 2^(Fan Out) − 1. В «Процессе согласования»: 3 + 1 = 4.

• CFC (общая сложность потока управления) — сумма всех вышеуказанных значений. Итоговый CFC для «Процесса согласования»: 2 + 17 + 4 = 23.

Структурные метрики

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

Дерево выполнения BPMN — это перевернутое дерево, ветвление которого создается через call activity.

• Плотность (Density) — отношение количества дуг (потоков последовательности) к максимально возможному числу дуг в графе. Формула: arcs / [nodes × (nodes − 1)]. Чем плотнее модель, тем хуже читаемость — больше «паутины» из стрелок. Для «Процесса согласования» плотность = 0.0431.

• CNC (Coefficient of Network Connectivity) — простое отношение количества дуг к количеству вершин. В «Кредитном кейсе» CNC = 1.2068.

• Длина (Length) — максимальная глубина модели по дереву.
  В BPMN — это сколько уровней вложенности подпроцессов или call activity. В CMMN учитываются также подстадии внутри stage и plan fragment. Длина «Кредитного кейса» = 3.

• NRC (Number of Referenced Children) — количество моделей, на которые ссылается текущая модель.

• NRP (Number of Referencing Parents) — количество моделей, которые ссылаются на текущую модель.

Метрики данных

Работа с данными — неотъемлемая часть моделей BPMN и CMMN. В Flowable оркестрации могут хранить информацию традиционно через переменные или более структурированно — с помощью data objects. Сложные модели часто содержат запутанные структуры данных.

• NVAR (Number of Variables) — количество переменных в модели. Показывает уровень сложности работы с данными.

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

В следующих статьях мы подробно разберем создание анализатора сложности и применение этих метрик на реальных примерах.

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

Об авторе
Prathamesh Mane
Flowable Solutions Architect

Пратаamesh — архитектор решений в компании Flowable. Он помогает клиентам проектировать, внедрять и оптимизировать решения интеллектуальной автоматизации. Благодаря глубоким знаниям BPMN, CMMN и DMN он умеет превращать техническую сложность в реальную бизнес-ценность и гарантирует, что Flowable работает именно там, где это важнее всего.

BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.