Когда документы согласуют в почте и мессенджерах, руководитель видит отдельные письма и комментарии, но не всегда понимает итог: у кого сейчас документ, все ли обязательные участники ответили и к какой версии относится их решение. Файл мог измениться после последнего согласования, а статус «готово» — остаться прежним.
Автоматизация согласования документов решает эту задачу, если система связывает маршрут, решения и замечания с конкретной версией. Одного уведомления или кнопки «согласовать» недостаточно. Сначала нужно описать полномочия людей, правила возврата и условия завершения, а затем перенести их в рабочую систему.
Это руководство посвящено организации рабочего процесса. Оно не определяет юридическую силу документа и не заменяет консультацию по электронной подписи или обязательным требованиям к документообороту.
Начните с одного повторяемого типа документа
Выберите документ, который проходит похожий путь из раза в раз. Для первого маршрута подойдёт процесс с понятным инициатором, известными участниками и наблюдаемым результатом. Название документа не так важно, как повторяемость правил.
До настройки ответьте на три вопроса:
- Кто создаёт документ и отвечает за его содержание?
- Кто должен проверить его до завершения маршрута?
- Что в вашем рабочем процессе означает статус «согласовано»?
Последний вопрос требует точного ответа. Для одной компании «согласовано» означает, что все обязательные участники одобрили одну версию. Для другой после этого нужен отдельный выпуск документа ответственным сотрудником. Система должна показывать реальный этап, а не присваивать финальный статус раньше времени.
Не стоит автоматизировать полномочия, которые команда ещё не определила. Если сотрудники спорят, кто принимает решение или чей ответ обязателен, настройка только перенесёт этот спор в интерфейс.
Составьте паспорт маршрута
Паспорт — короткое описание правил, по которым движется документ. Он помогает отделить постоянную логику от настроек конкретного сервиса.
| Поле | Что зафиксировать |
|---|---|
| Инициатор | Кто создаёт документ, отправляет его на согласование и отвечает за доработку |
| Версия | Как система присваивает номер или другой однозначный признак редакции |
| Обязательные участники | Чьё решение необходимо для завершения маршрута |
| Порядок | Кто проверяет последовательно, а кто может работать параллельно |
| Замечания | Где они хранятся, кому назначается исправление и как отмечается его результат |
| Замещение | Кто принимает задачу при отсутствии участника и на каком основании |
| Условия завершения | Какие решения должны быть получены именно по текущей версии |
| Доступ | Кто может читать документ, комментировать его и менять содержимое |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Сроки тоже относятся к правилам компании. Их нельзя брать из универсального шаблона: допустимое время зависит от типа документа, загрузки участников и последствий задержки. Если нужны напоминания или эскалация, заранее определите адресата и момент отправки.
Доступы должны соответствовать роли. Согласующему может быть разрешено читать документ и оставлять решение, но не менять исходный файл. Инициатору может понадобиться право создать новую версию, но не право подтвердить её от имени другого участника.
Разделите состояния документа
Понятный маршрут можно представить как последовательность состояний:
- Черновик. Инициатор готовит документ; согласование ещё не началось.
- Отправлено на согласование. Зафиксирована версия и назначены участники.
- Есть замечания. Один или несколько участников запросили изменения.
- Доработка. Ответственный меняет документ и выпускает новую версию.
- Повторная проверка. Нужные участники проверяют изменения по правилу маршрута.
- Утверждённая версия. Получены все обязательные решения, и каждое относится к одной версии.
Уведомление о задаче не равно решению. Факт доставки письма, открытия карточки или истечения срока нельзя показывать как согласование.
Молчание участника тоже не означает согласие. Автоматически пропустить его можно только по заранее утверждённому правилу: например, передать задачу назначенному заместителю. В журнале должно быть видно, почему изменился участник и кто принял решение.
Главное правило: решение относится к версии
Если после согласования изменилось содержание, прежнее решение нельзя автоматически переносить на новый файл. Система должна определить, что появилась новая версия, показать изменение и вернуть документ на предусмотренный этап.
Не каждое техническое действие обязано запускать полный маршрут заново. Компания может отдельно определить, какие изменения требуют повторной проверки и кто её проходит. Но это должно быть явным правилом, а не решением системы по догадке.
История документа должна отвечать на практические вопросы:
- кто и когда отправил версию на проверку;
- какое решение принял каждый обязательный участник;
- какие замечания он оставил;
- кто исправлял замечание;
- чем новая версия отличается от предыдущей;
- почему документ получил текущий статус.
Так руководитель проверяет не только финальную надпись, но и основание для неё.
Учебный пример: условный внутренний документ
Руководитель согласовал версию А плана работ. После этого инициатор изменил объём и создал версию Б. Версия Б не наследует согласование версии А автоматически: система показывает изменение и возвращает документ нужным участникам.
| Событие | Действие процесса |
|---|---|
| Согласующий оставил замечание | Система назначает владельца исправления и сохраняет связь с версией |
| Инициатор создал новую версию | Запускается повторная проверка по установленному правилу |
| Обязательный участник отсутствует | Задача переходит заместителю, если правило замещения утверждено заранее |
| Все обязательные решения получены | Итоговый статус присваивается именно проверенной версии |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Это условный пример для проектирования процесса, а не описание действующего клиентского внедрения. Он не устанавливает договорных условий и юридических последствий.
Что поручить ИИ, а что оставить людям
В таком процессе ИИ-помощник может собрать сведения для инициатора, подготовить сводку замечаний, напомнить о незакрытых вопросах и показать различия между версиями. Но итоговое решение принимает сотрудник с нужными полномочиями.
Сводка не должна подменять документ. Согласующий сверяет её с исходным текстом, особенно если изменение касается объёма работ, денег, обязательств или других существенных условий. Если помощник не уверен, он должен показать неопределённость или передать вопрос человеку, а не скрывать правку за краткой формулировкой.
Не каждому маршруту нужен ИИ-агент. Если событие всегда запускает одну и ту же последовательность, достаточно обычной автоматизации или интеграции: назначить задачи, сменить статус, отправить напоминание и записать решение. ИИ-агент уместен, когда системе нужно работать с неструктурированным текстом, выбирать разрешённый источник или готовить сводку. Чат-бот — только интерфейс диалога; сам по себе он не определяет правила согласования.
Switch On AI помогает спроектировать такие границы в рамках разработки ИИ-агентов: определить входные данные, разрешённые действия, участие человека и проверочные сценарии. Если задачу закрывает фиксированный маршрут, проект можно упростить до обычной автоматизации без агентной логики.
Как проверить маршрут перед запуском
Приёмка должна охватывать не только обычное успешное согласование. Подготовьте отдельные сценарии и для исключений.
| Проверка | Ожидаемый результат |
|---|---|
| Документ изменили после согласования | Новая версия не получает прежний финальный статус; нужные участники проверяют её повторно |
| Участник отказал | Процесс сохраняет решение и не показывает документ как утверждённый |
| Согласующий отсутствует | Срабатывает утверждённое правило замещения либо маршрут останавливается с понятным статусом |
| Два участника оставили замечания параллельно | Оба замечания сохраняются, у каждого есть автор, версия и владелец исправления |
| Инициатор повторно отправил документ | Система применяет установленное правило и не создаёт ложный второй итог |
| Пользователь без нужной роли открыл карточку | Документ и действия недоступны сверх выданных полномочий |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Допуск к запуску можно сформулировать так: решение однозначно связано с версией, история действий доступна ответственному, замечания не теряются, а статус не опережает реальные решения участников.
Учебный пример не доказывает, что конкретная система уже прошла эти проверки. Во время проекта команда должна сохранить входные данные, ожидаемый результат и фактическое поведение для каждого сценария. Подход к такой проверке подробнее описан на странице «Как работаем».
Что подготовить для обсуждения проекта
Возьмите один тип документа и опишите его текущий путь: кто создаёт, кто проверяет, где появляются замечания и что происходит после изменения файла. Добавьте обезличенный пример документа, список ролей и один сложный случай — отсутствие сотрудника, отказ или спор двух участников.
По этим материалам можно составить паспорт маршрута, определить, где достаточно фиксированных правил, а где полезен помощник для работы с текстом. Отдельно зафиксируйте критерии приёмки и действия, которые всегда требуют решения человека.
Чтобы обсудить автоматизацию со Switch On AI, опишите свой процесс: кто согласует документ, что происходит при изменении и как сейчас проверяют итоговую версию. Начнём с маршрута одного документа и не будем переносить в систему неописанные полномочия.
Вопросы по этой задаче
Кто должен утверждать документ в автоматизированном процессе?
Только сотрудники, чьи полномочия заранее закреплены в маршруте. Система назначает задачи, сохраняет решения и показывает статус, но не определяет полномочия вместо компании.
Что делать, если документ изменили после согласования?
Создать новую однозначно обозначенную версию и вернуть её на предусмотренный этап проверки. Решения по прежней версии нельзя автоматически считать решениями по изменённому документу.
Можно ли пропустить согласующего, если он не ответил вовремя?
Молчание не считается согласием. Пропуск или передача заместителю допустимы только по заранее утверждённому правилу, которое система отражает в истории.
Заменяет ли автоматизация согласования электронную подпись?
Нет. Описанный маршрут помогает управлять рабочими статусами, версиями и замечаниями, но сам по себе не устанавливает юридическую силу документа и не заменяет требования к электронной подписи.