Маршруты согласования договоров: как мы убираем почтовую цепочку юрист → руководитель → бухгалтерия

«Договор снова где-то у юриста» — эту фразу я слышу от клиентов регулярно, и почти всегда за ней стоит одна и та же картина: файл .docx летает по почте, в цепочке пять адресов в копии, ответственного за срок нет, а сам документ можно найти только по фразе «переслал вчера вечером». За несколько внедрений мы вывели рабочую схему: маршрут согласования договора живёт не в почте, а в 1С:Документооборот, с ролями вместо фамилий, с жёстким контролем сроков и без единого потерянного вложения. В этой статье — как мы это делаем технически, шаг за шагом, с конкретными настройками.

Почему цепочка «юрист → руководитель → бухгалтерия» через почту тонет на две недели

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

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

В сумме это и даёт те самые 8-14 рабочих дней, о которых чаще всего рассказывает клиент на первой встрече — оценка по нашей практике, не универсальный норматив, но воспроизводится у большинства компаний до 50 рабочих мест с похожей организацией процесса.

Наша методология: переносим маршрут из почты в 1С:Документооборот, а не изобретаем отдельную СЭД

У подавляющего большинства наших клиентов уже есть 1С — чаще всего 1С:Бухгалтерия или 1С:ERP/1С:Управление торговлей для учёта. Поэтому первое архитектурное решение, которое мы принимаем на старте, — не покупать отдельную систему электронного документооборота, а разворачивать 1С:Документооборот 3.0 рядом с учётной базой. Это даёт два практических плюса: сотрудники заходят под теми же логинами через единый портал, и договор в СЭД можно связать напрямую со справочником контрагентов и сделкой из учётной базы, а не заводить его как изолированный файл.

Редакция 3.0 отказалась от старой модели «комплексных процессов», которая была в редакции 2.1 — там маршрут рисовался как единая графическая схема с заранее прописанными развилками. Сейчас вместо этого используются правила обработки документов: для каждого вида документа (у нас это будет «Договор» и его подвиды) отдельно настраивается, какие действия выполняются, кто их выполняет и по каким условиям процесс движется дальше. Это архитектурно удобнее для нашей задачи: правило обработки договора не нужно перерисовывать каждый раз, когда меняется состав видов документов или организационная структура — оно живёт в разрезе вида документа, темы, организации и подразделения.

Выбор редакции — ПРОФ или КОРП — мы делаем по сложности будущего маршрута, а не по формальному числу пользователей. Редакция ПРОФ 3.0 закрывает базовый сценарий (последовательное или параллельное согласование, роли, эскалация) и для клиентов до 50 рабочих мест с одной юридической структурой обычно достаточна. КОРП добавляет более глубокую настройку сложных многоступенчатых процессов, управление проектами и корпоративные коммуникации — эта редакция нужна, если у клиента несколько юрлиц с разными правилами согласования или холдинговая структура с межорганизационными маршрутами. Мы принимаем решение после того, как нарисуем целевой маршрут на бумаге — если в нём больше двух развилок по условиям, смотрим в сторону КОРП.

Шаг 1: роли исполнителей и виды документов — фундамент, без которого маршрут развалится при первой кадровой замене

Первая ошибка, которую мы видим у клиентов, пытавшихся настроить согласование самостоятельно, — маршрут строится на конкретных сотрудниках: «отправить Ивановой, затем Петрову». Это работает ровно до первого отпуска, декрета или увольнения — маршрут встаёт, потому что жёстко привязан к физическому лицу. Мы всегда строим маршрут на ролях исполнителей, а не на фамилиях. Настройка ролей делается в разделе «НСИ и администрирование» → «Предприятие» → «Роли исполнителей».

Для типового маршрута договора мы заводим четыре роли: Юрист-эксперт (разрешает правовые риски и формулировки), Руководитель направления (утверждает условия и бюджет по своему подразделению), Ответственный за учёт (бухгалтерия — проверяет НДС, статью расходов, соответствие плану счетов) и Подписант (лицо, имеющее право подписи по доверенности или уставу). Каждая роль разрешается системой автоматически по атрибутам сотрудника — подразделению, должности или явному назначению в справочнике «Роли исполнителей», поэтому при замене человека на позиции маршрут менять не нужно вообще: система сама подставит нового исполнителя роли.

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

Шаг 2: правило обработки — собираем последовательно-параллельный маршрут вместо линейной почтовой цепочки

Ключевое отличие маршрута в 1С:Документооборот от почтовой цепочки — не все этапы обязаны идти строго друг за другом. Система поддерживает три варианта маршрутизации: последовательный, параллельный и смешанный (когда часть исполнителей работает параллельно, а часть — строго после предыдущего этапа). Именно смешанный режим даёт основной выигрыш по времени: юридическая экспертиза действительно должна идти первой (нет смысла считать бюджет по договору с неснятыми правовыми рисками), а вот проверку бюджета руководителем и проверку НДС/статьи расходов бухгалтерией можно и нужно пускать одновременно — это независимые проверки, которые в почтовой цепочке искусственно тянутся друг за другом просто потому, что письмо физически может быть только в одном месте одновременно.

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

При таком построении вместо суммы сроков (условно 4-5 дней на каждом линейном шаге в почте) мы получаем два последовательных блока и один параллельный, что по нашей практике укладывается в 3-4 рабочих дня для типового договора без спорных пунктов — это оценка по калибровке на нескольких внедрениях, а не гарантированный норматив для любого клиента.

Условная маршрутизация: система сама выбирает ветку по сумме, контрагенту и типу договора

Четырёхэтапный маршрут выше — это базовый сценарий, но реальная жизнь требует развилок: договор на 50 000 ₽ и договор на 5 000 000 ₽ не должны идти по одному и тому же пути. Здесь мы используем механизм условной маршрутизации — систему правил, которая сама определяет, куда движется документ дальше, без участия сотрудника, который иначе должен был бы каждый раз вручную решать, кому переслать письмо.

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

• по сумме — договоры свыше порогового значения (у каждого клиента свой, чаще всего это 1 000 000 ₽) дополнительно уходят на согласование генеральному директору, договоры меньшей суммы утверждает заместитель или руководитель направления;
• по контрагенту — договоры с новым, ранее не работавшим контрагентом, автоматически получают дополнительный этап проверки службой безопасности или юристом на предмет due diligence, договоры с постоянным проверенным контрагентом идут по укороченному маршруту;
• по типу договора — допсоглашения, не меняющие сумму и срок, проходят по сокращённому маршруту без повторного визирования руководителя, если это разрешено настройками правила.

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

Контроль сроков: эскалация задач вместо личного «напомните, пожалуйста»

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

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

Для маршрута договора мы обычно настраиваем два уровня эскалации: за 4 часа до истечения личного срока — напоminание тому же исполнителю без смены адресата, а через 24 часа после просрочки — перенаправление на роль «Руководитель подразделения исполнителя» с пометкой «просрочено подчинённым». Это единственный механизм во всей схеме, который реально снимает необходимость менеджеру вручную звонить и спрашивать «ну как там договор» — просрочка сама попадает туда, где на неё обратят внимание.

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

ВЫБРАТЬ
  ЗадачаИсполнителю.Ссылка.Наименование КАК Договор,
  ЗадачаИсполнителю.Роль,
  ЗадачаИсполнителю.Дата КАК Постановка,
  ЗадачаИсполнителю.ДатаЗавершения,
  РАЗНОСТЬДАТ(ЗадачаИсполнителю.Дата, ЗадачаИсполнителю.ДатаЗавершения, ЧАС) КАК ДлительностьЧасов
ИЗ
  Задача.ЗадачаИсполнителю КАК ЗадачаИсполнителю
ГДЕ
  ЗадачаИсполнителю.Выполнена = ИСТИНА
  И ЗадачаИсполнителю.Ссылка.ВидДокумента = &ВидДоговор

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

Уведомления, которые реально доходят: встроенные оповещения, мобильное приложение и наш Telegram-мост

Даже идеально настроенный маршрут не работает, если исполнитель не видит, что на нём висит задача. 1С:Документооборот уведомляет о новой задаче тремя штатными способами: значок с числом задач в интерфейсе программы, email-дайджест по расписанию и push-уведомление в мобильном приложении (доступно на iOS и Android, тот же логин, что и в веб-клиенте). На практике мы видим, что руководители среднего и топ-уровня открывают тонкий клиент 1С раз в день в лучшем случае, а почтовые дайджесты у них тонут в общем потоке писем точно так же, как тонула исходная цепочка согласования.

Поэтому поверх штатных каналов мы обычно добавляем свой мост в Telegram — это не часть типовой поставки 1С:Документооборот, а наша надстройка: регламентное задание раз в 15-30 минут проверяет новые и просроченные задачи по роли договора и отправляет короткое сообщение в личный чат с ботом через стандартный HTTP-запрос к Telegram Bot API. Технически это вызов из кода 1С (объект HTTPСоединение) либо, если регламент проще, обвязка через внешнюю утилиту, которую дёргает то же самое регламентное задание, что и эскалацию:

curl -s -X POST "https://api.telegram.org/bot<TOKEN>/sendMessage" \
  -d chat_id=<ID_исполнителя> \
  -d text="Договор №15: этап «Согласование бюджета» просрочен на 1 день, роль «Руководитель направления»"

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

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

Внутреннее согласование — это только часть проблемы. Даже когда маршрут внутри компании отработал за три дня, договор часто всё равно застревает на этапе физической передачи оригинала контрагенту и обратно. Здесь мы разделяем два разных механизма, которые в 1С:Документооборот не стоит путать. Первый — внутренний штамп согласования/подписания, который фиксирует факт визирования этапа внутри компании (кто, когда, с каким результатом прошёл этап) и не имеет юридической силы вовне — это внутренний контроль процесса, а не электронная подпись в смысле 63-ФЗ.

Второй механизм — подсистема 1С-ЭДО, встроенная в учётные конфигурации 1С и интегрируемая с 1С:Документооборот, которая нужна именно для юридически значимого обмена документами с контрагентом через оператора электронного документооборота по роумингу между операторами. Для подписания в 1С-ЭДО нужна усиленная квалифицированная электронная подпись и установленный криптопровайдер (в подавляющем большинстве внедрений — КриптоПро CSP) на рабочем месте подписанта. Мы разводим эти два контура сознательно: внутреннее согласование идёт по маршруту в 1С:Документооборот без всякой криптографии — это ускоряет процесс, а не замедляет его требованиями к сертификатам, а на внешний обмен с контрагентом документ уходит уже готовым, одним нажатием из карточки, без повторного набора реквизитов.

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

Пошаговый план внедрения: от аудита почтовой цепочки до работающего маршрута

Порядок, которого мы придерживаемся у клиентов до 50 рабочих мест — компактный и укладывается в одну-две недели активных работ плюс период калибровки:

1. День 1. Аудит текущей цепочки: собираем 10-15 последних согласованных договоров, по переписке восстанавливаем фактические сроки на каждом этапе — это и есть базовая точка отсчёта «было», с которой потом сравниваем результат.
2. День 2. Разворачиваем или используем существующую базу 1С:Документооборот 3.0, заводим виды документов (Договор и подвиды) и роли исполнителей, привязанные к подразделениям, а не к фамилиям.
3. День 3. Настраиваем правило обработки: последовательно-параллельный маршрут из четырёх этапов, личные и общий сроки, ответственный за результат.
4. День 4. Добавляем условную маршрутизацию по сумме и по контрагенту, включаем эскалацию задач с двумя уровнями (предупреждение до срока, перенаправление после просрочки).
5. День 5. Настраиваем уведомления: проверяем email-дайджест, ставим мобильное приложение ключевым согласующим, разворачиваем Telegram-мост для просроченных задач.
6. Неделя 2. Проводим первые 5-10 реальных договоров по новому маршруту в режиме наблюдения, без штрафных санкций за нарушение сроков — это калибровочный период, на котором мы донастраиваем сроки под фактическую загрузку конкретных сотрудников.
7. Через месяц. Снимаем отчёт по фактическим срокам прохождения (тем самым запросом по журналу задач) и сравниваем с базовой точкой из дня 1 — это единственный объективный способ показать клиенту разницу «было / стало», а не полагаться на субъективное ощущение «вроде стало быстрее».

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

Частые вопросы

Нам хватит редакции ПРОФ 1С:Документооборот, или сразу нужна КОРП?

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

Что будет с договорами, которые уже согласовываются по почте на момент перехода?

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

Что произойдёт с маршрутом, если юрист или бухгалтер уйдёт в отпуск в разгар согласования?

Ничего критичного, если маршрут изначально построен на ролях, а не на конкретных фамилиях — именно поэтому мы всегда настраиваем роли исполнителей через привязку к подразделению и правила замещения. Задача автоматически уходит замещающему сотруднику, назначенному в настройках замещения, а не зависает в личном почтовом ящике человека, которого физически нет на месте.

Сколько по факту занимает внедрение такого маршрута у клиента до 50 рабочих мест?

Активная настройка — 5 рабочих дней: роли, виды документов, правило обработки, условная маршрутизация, эскалация и уведомления. После этого мы закладываем 2-4 недели калибровки на реальных договорах, чтобы подогнать личные сроки этапов под фактическую загрузку конкретных сотрудников — универсального стартового значения, подходящего всем компаниям без калибровки, не существует.

Нужна ли квалифицированная электронная подпись для внутреннего согласования договора?

Нет. Внутренний маршрут (юрист, руководитель, бухгалтерия, подписант) в 1С:Документооборот работает через внутренний штамп согласования, который фиксирует факт визирования и не требует криптографии — это ускоряет процесс, а не создаёт барьер сертификатами. Усиленная квалифицированная подпись и криптопровайдер нужны отдельно, только на этапе юридически значимого обмена подписанным документом с контрагентом через подсистему 1С-ЭДО.