Как автоматизировать контроль сроков согласования и замещение согласующего

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

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

Когда согласование считается просроченным

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

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

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

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

Какие данные и полномочия зафиксировать до автоматизации

Для каждого согласования нужна карточка, по которой можно восстановить, кто, что и на каком основании должен решить. Минимальный состав:

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

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

Как представить ожидание и просрочку в состояниях процесса

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

1. Подготовлено — запрос ещё не отправлен.
2. Ожидает решения — действует запрос основному согласующему.
3. Напоминание отправлено — уведомление зафиксировано, но право решения не изменилось.
4. Просрочено — наступило контрольное событие, ответа нет.
5. Передано заместителю — полномочия проверены, действует новый ответственный.
6. Эскалировано — уполномоченного заместителя нет или нужна развилка владельца процесса.
7. Одобрено, отклонено или отозвано — ожидание завершено.

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

В облачных потоках Power Automate действие Start and wait for an approval запускает согласование и ожидает ответа назначенных согласующих до продолжения выполнения. Документация n8n описывает узел Wait: workflow можно приостановить и затем продолжить с сохранёнными данными выполнения. Эти возможности помогают организовать ожидание, но сами по себе не подтверждают готовые правила рабочего календаря, замещения, отмены прежнего запроса или защиты от одновременных ответов.

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

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

Напоминание сообщает согласующему:

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

Отправка сообщения не меняет решение и не передаёт полномочия. Статус «напоминание отправлено» нужен для истории доставки, а не для имитации результата согласования.

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

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

Как передать запрос заместителю

Непосредственно перед передачей система повторно проверяет:

1. Замещение действует в текущий момент.
2. Оно распространяется на нужный тип решения.
3. Заявка не отозвана, а версия материалов не изменилась.
4. Основной согласующий ещё не дал действующий ответ.
5. Новый запрос можно связать с исходной заявкой и её историей.

Заместитель получает контекст, актуальные материалы, срок, причину передачи и историю уведомлений. Система не подготавливает за него формальное решение.

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

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

Когда и кому эскалировать просрочку

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

После эскалации владелец процесса может по утверждённому правилу:

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

Истечение срока не даёт системе права автоматически одобрить заявку. Такое действие подменило бы человеческое решение и могло бы обойти установленные полномочия.

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

Условный пример просроченного согласования

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

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

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

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

Подходящего заместителя нет. Заявка получает статус «требуется решение владельца процесса» и уходит на эскалацию. Автоматического одобрения не происходит.

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

Проверка, ограничения и подготовка внедрения

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

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

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

Отдельно проверяют права пользователей, источник рабочего календаря, актуальность замещения, доставку уведомлений, повтор событий и восстановление выполнения. Документация Power Automate и n8n подтверждает отдельные возможности ожидания и построения workflow, но не доказывает наличие готового механизма замещения, эскалации или защиты от гонок в конкретной конфигурации. Фактические API, лицензии, права, способы отмены запросов и совместимость проверяются для выбранных систем.

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

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

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