Всем привет, меня зовут Сергей Прощаев, и в этой статье расскажу про то, как перевести согласование договора с последовательной цепочки на параллельные ветки в новом конструкторе бизнес‑процессов Битрикс24 и не получить процесс, который зависает на ровном месте.

Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС. Бизнес‑процессы Битрикс24 я разбираю глазами бэкендера: для меня это ещё один движок оркестрации, и болезни у него те же, что у Camunda.

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

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

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

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

Ниже — маршрут из семи шагов, две схемы, таблица решений, модель сбоев и чек‑лист проверки. Кода почти не будет: главный объект разбора здесь — сам маршрут.

Цифры «4 дня вместо 8» в заголовке — модельный сценарий, а не обещание: откуда они берутся, покажу на рис. 2.

Исходные условия

Чтобы разговор был предметным, зафиксирую, с чем работаем. Это типичная конфигурация для компании со штатом 100–300 сотрудников, которая уже живёт в Битрикс24.

• Платформа. Облачный Битрикс24 с новым конструктором бизнес‑процессов (в интерфейсе — «Бизнес‑процессы AI»). Его раскатывают на порталы постепенно, и доступен он не на всех тарифах. Настраивать его может только администратор портала.

• Где живёт договор. Смарт‑процесс «Договоры» (подойдёт и сделка). Поля: сумма, тип договора, контрагент, файл, а также отдельные поля статуса и замечаний на каждого согласующего.

• Кто согласует. Юрист, финансист, служба безопасности (только если сумма выше порога, условно 1 млн ₽) и руководитель, который утверждает последним.

• Регламент. На решение даётся 2 рабочих дня по производственному календарю портала, дальше эскалация: уведомление руководителю отдела, право решения остаётся у согласующего.

И одно честное ограничение сразу. Я описываю поведение нод по официальной документации Битрикс24 в редакции лета 2026 года и по тому, что обычно проверяю на тестовом портале. Интерфейс конструктора активно обновляется, поэтому названия кнопок у вас могут немного отличаться. Логика маршрута от этого не меняется.

Почему последовательная цепочка — это сумма, а не максимум

В последовательном маршруте срок согласования равен сумме всех проверок. В параллельном — самой долгой проверке плюс финальный шаг. Если записать формулами:

// (псевдокод) критический путь согласования
T_посл = T_юрист + T_финансы + T_СБ + T_руководитель
T_пар  = max(T_юрист, T_финансы, T_СБ) + T_руководитель

Вторая формула верна при трёх условиях: проверки могут стартовать одновременно, их результаты не зависят друг от друга, и у согласующих хватает ёмкости. К последнему условию я ещё вернусь.

Мне как‑то попалась хорошая формулировка у разработчиков CLM‑систем: параллелить стоит независимые проверки, а последовательными оставлять только те, где следующему нужен результат предыдущего (Sirion). Там же предлагают гибрид: сначала параллельный кластер, потом последовательное утверждение. Это ровно наша схема.

Посмотрите на рис. 2. Один и тот же договор проходит два маршрута. Регламент даёт каждому 2 рабочих дня, но в модельном сценарии юрист, как это часто бывает, тратит 3 и просрочивает SLA на день. Финансист и служба безопасности укладываются в 2 дня, руководитель — в 1.

Главное, что стоит вынести из рис. 2: ускорение появляется не потому, что люди начинают работать быстрее.

Юрист по‑прежнему тратит свои 3 дня и даже нарушает SLA. Исчезает только ожидание в очереди, а в последовательном маршруте оно занимает половину срока. Заодно видно, что просрочка одного согласующего в параллельном маршруте не складывается с работой остальных: руководитель стартует, как только завершится последняя из трёх веток.

Но у этой картинки есть честная оговорка. Параллельность сокращает критический путь одного договора, но не уменьшает объём работы. Если в неделю приходит 100 договоров, каждый согласующий по‑прежнему должен обработать все 100. Меняется только момент, когда они к нему попадают: не волной после соседа, а сразу.

При ограниченной ёмкости очередь просто переедет из ожидания между этапами в очередь конкретного человека, и 4 дня с рис. 2 снова превратятся в 8. Поэтому до перехода я смотрю не только на схему, но и на загрузку каждого согласующего.

Есть и второй эффект, который я ценю даже больше скорости.

Помню, как в одном FinTech‑проекте мы подключали нового платёжного провайдера. Договор шёл классической цепочкой и на седьмой день добрался до службы безопасности. У СБ возникли вопросы к структуре владения контрагента, и половину текста пришлось переписывать. Юрист, который всё уже вычитал, делал работу второй раз. А интеграция с провайдером к тому моменту была готова и две недели лежала за фиче‑флагом, пока договор ходил по второму кругу. В параллельном маршруте блокирующее замечание всплыло бы в первый же день.

World Commerce & Contracting вместе с Deloitte исследовали более 1 200 организаций. Средняя эрозия стоимости контрактов у них получилась 8,6%: у лучших — чуть больше 3%, у худших — свыше 20% (WorldCC, Deloitte).

Одной из причин авторы называют раздробленность контрактного процесса: он размазан по людям и системам, и никто не видит его целиком. Медленное последовательное согласование — один из симптомов такой раздробленности, а не единственный источник потерь.

Маршрут: семь шагов в новом конструкторе

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

Шаг 1. Разделите проверки на независимые и зависимые

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

Как проверить. Если про какую‑то ветку хоть раз прозвучало «пусть сначала посмотрит юрист», она на самом деле последовательная. Лучше честно вынести её после слияния, чем получить параллельность только на схеме.

Шаг 2. Опишите маршрут текстом и соберите каркас

Мой вариант, который я обычно использую, — короткая текстовая спецификация. Её читают юрист и финансист, и спорят о логике они до того, как администратор потратит день на ноды.

# (YAML) условная нотация для согласования маршрута с участниками, не формат Битрикс24
trigger: "Договор переведён на стадию «Согласование»"
guard: "раунд уже идёт — второй экземпляр не запускаем"
snapshot: [файл договора, сумма, контрагент]   # копия на старт раунда, только чтение
triage: "AI-подсказка; при ошибке AI — самая строгая схема"
parallel:
  lawyer:   {sla: "2 рабочих дня", on_timeout: "уведомить руководителя юротдела"}
  finance:  {sla: "2 рабочих дня", on_timeout: "уведомить финансового директора"}
  security: {when: "сумма > 1 000 000 или флаг AI", sla: "2 рабочих дня",
             on_timeout: "уведомить руководителя СБ", else: "NOT_REQUIRED"}
terminal_ok: [APPROVED, APPROVED_WITH_COMMENTS, NOT_REQUIRED]
join: "ждём все три ветки"
decide:                          # проверяется сверху вниз
  any_rejected: "вернуть инициатору со всеми замечаниями"
  any_approved_with_comments: "инициатор явно принимает замечания или отправляет на доработку"
  otherwise: "утверждение руководителем"
  default: "задача администратору"
max_rounds: 3   # отказ в третьем раунде — эскалация вместо четвёртого круга

Каркас в конструкторе выглядит так: триггер на смену стадии, затем универсальная нода смарт‑процесса.

1. Первым делом она проверяет поле «Статус согласования». Если там уже «Идёт раунд», новый экземпляр сразу завершается. Это защита от повторного запуска: договор вернули на прошлую стадию и снова перевели вперёд, и без такой проверки по нему пойдут два согласования одновременно.

2. Если раунда нет, нода ставит «Идёт раунд», записывает время старта в поле «Раунд начат», сбрасывает статусы всех согласующих в «Ожидает», очищает замечания прошлого круга и прибавляет единицу к полю «Номер раунда».

Честная оговорка для тех, кто мыслит гонками. Это обычный check‑then‑set: прочитали поле, потом записали.

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

Отчасти помогает сама платформа. В облачном Битрикс24 автозапускаемые процессы на одном элементе CRM выполняются по очереди, а процессов с ожиданием на одном элементе одновременно может быть не больше двух (Битрикс24). Но это лимит, а не гарантия идемпотентности.

У него есть и обратная сторона: если на договоре уже висят два других процесса с ожиданием, наше согласование не стартует, пока один из них не завершится. Если двойной раунд для вас критичен, запуск стоит вынести во внешний сервис с уникальным ключом «договор + номер раунда», а процесс стартовать через REST. Для большинства компаний хватает проверки на входе, но этот риск я явно записываю в ограничения.

Есть и обратная проблема — флаг без владельца. Если экземпляр упал или его остановили после записи «Идёт раунд», договор больше нельзя отправить на согласование. Поэтому нужна процедура восстановления.

Раз в сутки отдельный процесс с триггером «Запуск по расписанию» находит договоры, где «Идёт раунд» стоит дольше срока раунда с запасом, и ставит администратору задачу. Администратор сверяет договор со списком активных процессов в разделе «Автоматизация > Бизнес‑процессы > Процессы». Если живого экземпляра нет, он снимает флаг и запускает раунд заново.

Отдельно про версию документа.

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

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

Правило модели при этом не меняется: одобрение относится к снимку раунда, а любая правка текста — это новый раунд с новым снимком.

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

Второй прогон: переведите тестовый договор на стадию «Согласование» дважды подряд, второй экземпляр должен завершиться сам.

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

Шаг 3. В каждой ветке — решение с таймером

Внутри ветки удобно использовать ноду «Параллельное ожидание действия». Она ведёт процесс по той ветке, чьё событие случилось первым (Битрикс24).

• В начале одной ветки ставим «Команду»: согласующий выбирает решение.

• В начале другой — «Паузу». Сработала пауза раньше — уходит эскалация.

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

Если нужна передача ответственности, это другой маршрут: после паузы ветка ждёт уже решения руководителя, и это надо явно нарисовать. Смешивать оба варианта в одной схеме — верный способ получить спор «кто должен был согласовать».

С паузой есть тонкость: «2 рабочих дня» и «48 часов» — это разные контракты. Задание, выданное в пятницу вечером, по часам истечёт в воскресенье. «Пауза» умеет ждать промежуток времени или конкретную дату (Битрикс24), поэтому я ставлю её до даты.

Дедлайн считаю отдельно: в классическом дизайнере для этого есть функция addworkdays, которая прибавляет к дате рабочие дни (Битрикс24). Если в вашей версии нового конструктора её нет среди подстановок, посчитайте дедлайн заранее и храните его в поле карточки. И помните про часовые пояса: время задания каждый сотрудник видит в своём (Битрикс24).

Главное правило этого шага: каждая ветка пишет только в свои поля. «Статус юриста», «Замечания юриста», «Статус финансиста» и так далее. Никакого общего поля «Комментарий согласования».

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

Если обе ветки делают «прочитал — дописал — сохранил», это классический lost update.

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

И ещё: отказ без комментария не принимаем. Сразу после «Команды» ставлю ноду «Условие»: если выбрано «не согласовано», а поле замечаний пустое, согласующему уходит уведомление, и ветка снова ждёт его решения.

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

Шаг 4. Слияние потока и ловушка условной ветки

Нода «Слияние потока» объединяет параллельные ветки: процесс идёт дальше, только когда выполнились обе (Битрикс24). Это классический AND‑join, и здесь прячется самая дорогая ошибка.

Хочется поставить условие перед развилкой: «если сумма больше миллиона — запускаем ветку СБ». Для небольших договоров ветка СБ тогда не стартует вообще. А слияние продолжает её ждать.

Движок не считает это ошибкой: ветка просто никогда не дойдёт до слияния, и экземпляр будет висеть «в работе», пока его не остановят вручную или пока не сработает общий предел — Битрикс24 автоматически останавливает бизнес‑процесс через год после запуска (Битрикс24).

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

Инвариант здесь простой: у каждой обязательной ветки должен быть гарантированный путь к слиянию. Поэтому ветка СБ запускается всегда.

Её первая нода — «Условие»: если сумма не выше порога и AI не поднял флаг «нужна СБ», ставим статус «не требуется» и сразу идём к слиянию. Для слияния это такое же успешное завершение, как «согласовано».

В остальных случаях в ветке работает та же пара «Команда» и «Пауза», что у юриста: проверку контрагента делает человек, и у него тот же SLA.

И нюанс про количество веток. В документации «Слияние потока» описано для двух веток. Для трёх я собираю каскад: сначала сливаю юриста и финансиста, затем результат со службой безопасности.

Если в вашей версии конструктора нода принимает больше входов, проверьте это на тестовом портале, прежде чем упрощать схему.

Как проверить. Прогоните договор на 300 тысяч рублей. Процесс должен дойти до руководителя, а не остановиться на слиянии.

Шаг 5. Правило решения после слияния

После слияния ставим ноду с группами условий. Конструктор проверяет группы сверху вниз и выполняет первую подошедшую (Битрикс24).

Поэтому порядок такой:

1. сначала «есть хотя бы одно „не согласовано“»;

2. потом «есть „согласовано с замечаниями“»;

3. и только в конце «всё согласовано».

Про «согласовано с замечаниями» стоит договориться отдельно.

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

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

Вторая ловушка — в «Блоке условий»: если не выполнилось ни одно условие, процесс останавливается (Битрикс24).

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

Теперь спорный момент. Юрист отклонил договор в первый же день, а финансист ещё читает. Отменять его ветку? Я бы предпочёл не отменять. Пусть раунд закончится, и инициатор получит все замечания одним списком: два раунда доработки по очереди почти всегда дольше одного полного.

Исключение — стоп‑фактор от СБ, например контрагент в санкционном списке. Дорабатывать там нечего, и процесс я прерываю нодой «Прерывание процесса». Продолжить прерванный процесс с того же места нельзя (Битрикс24), поэтому перед прерыванием я уведомляю юриста и финансиста, что их задания больше не нужны, и ставлю договору статус «Заблокирован».

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

Здесь же проверяем поле «Номер раунда» из шага 2, и делаем это до запуска нового круга. Если отказ пришёл в третьем раунде, четвёртого не будет: договор уходит на эскалацию руководителю. Это уже не доработка, а спор между людьми, и решает его человек, а не очередной цикл согласования.

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

Шаг 6. AI‑нода — сортировщик, а не согласующий

В новом конструкторе есть AI‑ноды: они анализируют текст и могут выбрать ветку процесса (Битрикс24). Соблазн понятен: пусть AI сам согласует типовые договоры. Я бы так не делал.

Мой вариант: AI‑нода стоит на входе и работает как сортировщик. Она определяет тип договора и отмечает, менялись ли пункты об ответственности относительно шаблона. Результат уходит юристу подсказкой в карточку, а решение остаётся за человеком.

Для юридического риска ошибки несимметричны. Ложная тревога стоит юристу пяти минут, а пропущенный риск — денег и суда. Поэтому в моей схеме AI может только добавлять проверки, но не отменять их: он может поднять флаг «нужна СБ» для договора ниже порога, а выключить юриста — нет. Этот флаг ветка СБ читает в первом же условии.

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

На любой ошибке AI‑нода у меня уходит в выход по умолчанию: флаг «нужна СБ» ставится, подсказка юристу — «AI недоступен». Худшее, что происходит при сбое AI, — договор проверяют по самой строгой схеме, как до его появления.

По тому же принципу AI в 2026 году встраивают и в BPMN‑движки. Минорный релиз Camunda 8.9 официально датирован 14 апреля 2026 года (Camunda), и агентная оркестрация — одно из главных направлений релизного цикла (Camunda).

Сама Camunda описывает агентов как полноправных участников процесса, которые наследуют те же паттерны, что и детерминированные шаги: эскалацию по времени, обработку исключений, компенсацию (Camunda).

Как проверить. Соберите эталонный набор: 50–100 прошлых договоров, по которым юрист уже вынес решение, с ожидаемым типом и списком изменённых пунктов. Прогоните их через AI‑ноду и считайте отдельно пропуски (риск был, AI его не увидел) и ложные тревоги. Пока на этом наборе есть пропуски, AI‑нода только подсказывает и ничего не маршрутизирует. Набор храните и прогоняйте заново после каждого изменения промпта или модели.

И отдельно отключите AI на тестовом портале: договор должен пройти по самой строгой схеме со всеми проверками.

Шаг 7. Публикация и живые экземпляры

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

Для продакшена из этого следуют три разных случая. Новые договоры идут по новой схеме.

Здоровые старые экземпляры спокойно доходят до конца по старой. А зависшие старые сами не оживут: публикация исправленного шаблона их не лечит. Их придётся найти и перезапустить по процедуре восстановления из шага 2.

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

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

Схема целиком

Как семь шагов складываются в один маршрут, показано на рис. 3. Я рисовал его близко к тому, что вы увидите на полотне конструктора: защита от повторного запуска, запасной выход для AI, ветки с ожиданием и таймером, каскад слияний и решение после них.

Главное на рис. 3: ветки встречаются только в слияниях, а все условия живут внутри веток или после слияния. Если в вашей схеме условие стоит между развилкой и слиянием и может отрезать ветку целиком, там почти наверняка будет зависание. Рисунок получился объемный, поэтому оставлю ссылку в mermaid.live чтобы можно было позумить.

Модель сбоев: что может пойти не так

Все ловушки из шагов выше удобно свести в одну таблицу. Я держу её рядом при ревью любого маршрута согласования, не только в Битрикс24.

Если для какой‑то строки в вашем маршруте нет правого столбца, это и есть следующий инцидент.

Проверка результата: девять прогонов до запуска

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

• Счастливый путь. Все согласовали в срок. Руководитель получил задание ровно один раз, а не по разу от каждой ветки.

• Отказ плюс согласие. Юрист отклонил, финансист согласовал. Инициатору пришла одна задача с замечаниями обоих.

• Молчание. Финансист не отвечает. Уведомление руководителю пришло через 2 рабочих дня, а не через 48 часов, а решение по‑прежнему ждут от финансиста.

• Маленький договор. Сумма ниже порога, флага AI нет. СБ получила статус «не требуется», процесс дошёл до руководителя. Тот же договор с флагом AI ушёл в СБ.

• Второй и третий раунд. После доработки статусы сброшены, замечания прошлого круга очищены, в работе новый снимок файла. Отказ в третьем раунде ведёт к эскалации, а не к четвёртому кругу.

• Повторный запуск и флаг без владельца. Договор дважды подряд перевели на стадию «Согласование» — работает один экземпляр. Флаг «Идёт раунд» без живого процесса — администратор получил задачу. Почти одновременный запуск тестом надёжно не воспроизвести, это известное ограничение.

• Сбой AI. AI‑нода отключена или вернула ошибку. Договор прошёл по самой строгой схеме, процесс не встал.

• Стоп‑фактор. СБ нашла стоп‑фактор. Договор получил статус «Заблокирован», у юриста и финансиста не осталось висящих заданий.

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

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

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

Если хотите заодно проверить, насколько уверенно ориентируетесь в бизнес‑процессах и автоматизации Битрикс24, можно пройти бесплатный короткий вступительный тест. Он поможет увидеть темы, в которых стоит разобраться глубже.

Где это решение не сработает

Параллельность — не универсальное лекарство. Вот случаи, где я бы её не включал или включал частично.

• Проверки на самом деле зависимы. Финансист считает штрафы по редакции, которую ещё правит юрист. Тогда это последовательный шаг, и честнее его так и нарисовать.

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

• Узкое место — один человек. Если директор утверждает всё и отвечает через неделю, параллельные ветки до него сократят только первую часть пути.

• Мало согласующих на большой поток. Если юрист один на сотню договоров в неделю, параллельность не уберёт очередь, а переместит её к нему.

• Десятки согласующих с динамическим составом. В холдинге с согласованием по 10–15 подразделениям каскад слияний превращается в спагетти. «Итератор» выполняет действие для каждого значения списка (Битрикс24) и удобен, чтобы разослать однотипные задания. Но сбор результатов, ожидание всех и смену состава согласующих он сам не решает: это придётся проектировать отдельно или брать специализированную СЭД.

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

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

История: рабочий процесс, который отвергли пользователи

Есть показательный кейс, который интегратор ИНТЕРВОЛГА опубликовал в своём блоге ещё в 2017 году. Конструктор с тех пор сменился, а вывод — нет.

Заказчик — сеть магазинов фиксированных цен: около 140 магазинов и 300 сотрудников. Согласование договоров сначала собрали на стандартном конструкторе бизнес‑процессов, потратив 30 часов. Технически процесс работал. Но когда его начали тестировать реальные пользователи, отзывы оказались негативными.

Людям не хватало общего списка договоров со статусами. Они не видели, у кого сейчас документ, а процесс не использовал привычные им задачи. Процесс переделали с нуля. На каждого согласующего ставилась отдельная задача со сроком в 2 рабочих дня. У каждого был свой статус из четырёх: ожидает, согласовано, согласовано с замечаниями, не согласовано. Статус всего документа вычислялся из их сочетания.

Отказ или замечание без комментария система не принимала, а о просрочке сразу узнавали два руководителя.

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

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

Список или канбан смарт‑процесса показывает по ним картину по всем договорам сразу. А нодой «Установить результат бизнес‑процесса» итоговый файл можно зафиксировать как результат процесса, и он будет виден в списке завершённых (Битрикс24).

Вывод: параллельность — это про слияние, а не про развилку

Если свести статью к шпаргалке для закладок, получится восемь правил:

1. Параллелим только независимые проверки, зависимые ставим после слияния, и помним про ёмкость согласующих.

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

3. Раунд согласует снимок документа с правами только на чтение, любая правка текста — новый раунд.

4. Каждая ветка пишет только в свои поля статуса и замечаний.

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

6. У каждой обязательной ветки есть гарантированный путь к слиянию.

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

8. AI сортирует и подсказывает, может добавить проверку, но не отменить её, а при сбое маршрут идёт по самой строгой схеме.

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

А как у вас: ждёте всех согласующих до конца раунда или прерываете процесс на первом отказе? Интересно сравнить опыт в комментариях.

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

Если хочется покопаться в этих задачах глубже, в OTUS скоро пройдут два бесплатаных занятия:

• 7 октября в 20:00. «Поиск, выбор и получение данных из элементов для использования внутри бизнес‑процесса». Записаться

• 21 октября в 20:00. «Автоматизация цифровых рабочих мест». Записаться

Полный список вебинаров октября собрали в дайджесте.