Вернуться в блог
WorkflowСогласованиеРуководство

Как выстроить цепочку согласования, которая не тормозит работу

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

Команда BPM2 мин чтения

Проблема не в том, что согласования нет

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

Такая цепочка создаёт видимость контроля, но не контроль. Когда подпись ничего не значит, никто не читает, что подписывает.

Начните с вопроса «что изменится от его отказа»

Это главный фильтр. Прежде чем добавить участника в цепочку, спросите: если он откажет — что произойдёт?

  • Ответ есть — заявка вернётся на доработку, сумму урежут, поставщика поменяют. Участник нужен.
  • Ответа нет — «он должен быть в курсе». Это не согласование, это уведомление. Такому человеку не нужна кнопка «Согласовать» — ему нужна подписка на события.

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

Три-четыре этапа хватает почти всегда

На практике работающая цепочка выглядит так:

Инициатор → Руководитель отдела → Финансы → Директор

Причём последний этап включается не всегда, а по условию — например, только для заявок дороже определённой суммы. В BPM это задаётся правилом: тип заявки, сумма, приоритет.

Если у вас получается шесть и более этапов, почти наверняка часть из них — это подписчики, а не согласующие.

Когда параллельное согласование лучше последовательного

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

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

В BPM есть два параллельных режима, и разница между ними принципиальная:

  • Все (PARALLEL_ALL) — согласовать должны все участники. Подходит для юриста и безопасности: пропустить одного нельзя.
  • Любой (PARALLEL_ANY) — достаточно одного. Подходит для взаимозаменяемых ролей: в отделе три ведущих специалиста, заявку может закрыть любой свободный.

Второй режим сильно сокращает простои из-за отпусков и командировок.

Что делать с «застрявшими» заявками

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

  1. Видимость. В реестре заявок сразу видно, на ком остановился документ и сколько он там стоит. Не нужно никому звонить, чтобы это выяснить.
  2. Сроки. У заявки есть дедлайн, просроченные подсвечиваются. Это работает лучше напоминаний, потому что видно всем, а не только исполнителю.
  3. Возврат вместо отказа. Если чего-то не хватает, заявку возвращают инициатору с комментарием, а не отклоняют. Цепочка не начинается с нуля.

Правило вместо ручной сборки

Главная идея: цепочку не должен собирать человек под каждую заявку. Он ошибётся, забудет участника или добавит лишнего.

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

Так согласование перестаёт зависеть от того, кто именно создал заявку и насколько хорошо он помнит регламент.


Хотите посмотреть, как ваши правила лягут в систему? Напишите нам — соберём вашу цепочку на демо.