Параллельное или последовательное согласование: как выбрать маршрут и зафиксировать итоговое решение

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

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

Что именно должно решить согласование

Сначала определите объект решения. Это может быть заявка, документ или запись в рабочей системе. У объекта должны быть владелец, актуальная версия и понятное действие после итогового решения. Для каждого участника укажите допустимые ответы: например, «согласовать», «отказать» или «вернуть на доработку».

Не объединяйте разные роли одним словом «участник»:

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

Полномочия и допустимые решения утверждает заказчик со своими профильными специалистами. Автоматизация назначает задачи, фиксирует ответы и применяет согласованные правила. Она не принимает вместо сотрудников профессиональные, финансовые или юридические решения.

Минимальная карточка объекта выглядит так:

Чем различаются параллельный и последовательный маршруты

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

Официальная документация Power Automate описывает тип Sequential approval: запросы направляются согласующим по одному в заданном порядке, а каждый участник должен ответить до перехода к следующему. Это подтверждённое поведение конкретного типа согласования Power Automate, а не свойство любой системы.

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

Как выбрать маршрут по зависимостям между решениями

Для каждой роли ответьте на четыре вопроса:

1. Какую часть объекта проверяет участник?
2. Нужны ли ему выводы или комментарии коллег?
3. Может ли его решение изменить предмет следующей проверки?
4. Допустимо ли начать его работу одновременно с другими?

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

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

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

Одного ответа достаточно или должны ответить все

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

• порядок задач — кто и когда получает запрос;
• условие завершения действия согласования — после какого события техническое ожидание заканчивается;
• итоговый бизнес-статус — что решение означает для всей заявки и какое действие разрешает.

Возможны разные правила:

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

В Power Automate тип First to respond завершает запрос после одобрения или отказа любого назначенного согласующего. В типе Everyone must approve для положительной ветки нужны ответы всех, но один отказ запускает последующие действия досрочно. Оба утверждения относятся к действию Power Automate, описанному в документации.

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

Как вычислить и зафиксировать итоговое решение

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

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

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

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

Отказ, расхождение ответов и изменение заявки

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

В статье журнала Битрикс24 описан один вариант маршрута: отказ останавливает процесс, инициатор получает комментарий, вносит правки и запускает согласование заново. Это пример из материала вендора, а не техническая документация, испытание аккаунта или опыт Switch On AI. Возможность воспроизвести такое поведение зависит от редакции продукта, тарифа, прав и конфигурации конкретного портала.

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

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

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

Условный маршрут с параллельной группой и финальным этапом

Ниже — синтетический учебный пример. Это не клиентский кейс, не выполненный тест и не готовый регламент. Роли, ответы и состояния нужно заменить правилами конкретной организации.

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

Состояния учебного маршрута можно представить так:

1. Инициатор отправляет версию V1.
2. Две независимые задачи открываются параллельно.
3. Система вычисляет итог группы по утверждённому правилу.
4. После двух согласий директор получает V1 и принимает финальное решение.

Исключения тоже входят в схему:

• Отказ до второго ответа. Группа получает состояние «отклонено». Вторую задачу система закрывает или отзывает так, как указано в требованиях.
• Расхождение. Если оба участника согласовали заявку, но указали несовместимые условия, объект переходит ответственному за ручной разбор. Положительный итог группы в этом случае не вычисляется автоматически.
• Изменение заявки. При изменении суммы или состава работ появляется V2. Применимость решений по V1 определяет утверждённый регламент; директор не должен незаметно согласовать V2 по ответам, данным для V1.
• Повторный ответ. Повтор не создаёт второй итог и не запускает исполнение ещё раз.
• Запоздалый ответ. Ответ после закрытия группы фиксируется или отклоняется по проектному правилу, но сам по себе не меняет рассчитанный бизнес-статус.

Такая схема показывает требования к будущему решению. Она не подтверждает наличие всех механизмов в выбранном продукте.

Как проверить маршрут перед рабочим запуском

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

Дополнительно проверьте:

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

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

Что подготовить для обсуждения внедрения

Чтобы обсудить автоматизацию, подготовьте:

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

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

Switch On AI может помочь описать маршрут, проверить доступные способы подключения и подготовить интеграцию под согласованную операцию. Работа начинается с созвона и разбора процесса, затем готовятся техническое задание и коммерческое предложение. До договора можно показать бесплатный прототип ключевого сценария; прототип не равен полноценному внедрению. После согласования следуют договор, разработка и приёмка.

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