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

Почему согласование по почте и в мессенджерах ломается

Пока договоров несколько в месяц и согласующих двое, пересылка работает. Отказывает она на объёме и параллельности — и всегда одинаково:

• Никто не знает, у кого сейчас договор. Ответ на вопрос «где документ» — это опрос по чатам, а не взгляд на экран.
• Версии живут своей жизнью: «Договор_финал_v7_правки(2).docx» правят два согласующих параллельно в разных копиях, и чьи-то замечания теряются при слиянии.
• Замечания разбросаны: часть в письме, часть в чате, часть в комментариях файла. Собрать полную картину правок к третьему кругу уже невозможно.
• Сроков нет: документ лежит у согласующего неделями, и об этом узнают, когда контрагент напоминает о себе сам.
• Отпуск или увольнение одного согласующего молча останавливает цепочку — передача «висящих» документов нигде не зафиксирована.
• После подписания нельзя доказать, кто согласовал именно эту редакцию: в переписке есть «ок», но к какой версии файла он относился — вопрос веры.
• У руководителя нет картины: сколько договоров в работе, сколько просрочено, на ком стоят — эти данные в почте не существуют в принципе.

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

Что такое система согласования документов в организации

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

• Одна актуальная версия документа; правки и замечания привязаны к конкретной версии, а не гуляют по переписке.
• Маршруты трёх типов: последовательные (юрист → финансы → директор), параллельные (юрист и финансы одновременно) и условные — состав согласующих зависит от параметров документа.
• Статус и срок на каждом шаге: видно, у кого документ, сколько он там лежит и когда шаг просрочен.
• Уведомления и эскалация: просроченный шаг поднимается руководителю сам, а не когда «вспомнили».
• Замещения: отпуск согласующего не останавливает маршрут — документы уходят заместителю по правилу, а не по договорённости в курилке.
• История и аудит: кто, когда, какую версию согласовал или отклонил и с какой формулировкой. Это и есть ответ на спорные ситуации после подписания.

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

Электронная система согласования документов: СЭД, ЭДО или модуль своей системы

Под «автоматизировать согласование» на рынке продаются четыре разные вещи, и путаница между ними стоит денег. Честное сравнение выглядит так:

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

Когда хватит готовой СЭД

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

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

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

Когда согласование строят в своей системе

Свой модуль согласования становится оправданным, когда согласуется не документ сам по себе, а операция с данными — и маршрут от этих данных зависит:

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

Автоматизация договорной работы: не только маршрут согласования

Согласование — самый заметный, но не единственный кусок договорной работы. Если строить модуль под договоры, стоит сразу смотреть на весь жизненный цикл документа:

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

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

Сколько стоит автоматизация согласования договоров

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

1. 1Разбор процесса — 1–2 недели. Какие документы, какие маршруты, кто согласует, где сейчас теряется время. Результат — карта MVP: роли, маршруты, модули, этапы.
2. 2MVP — 4–8 недель. Ключевой маршрут целиком: документы, версии, согласующие, статусы, первый отчёт. Работающая система, а не прототип.
3. 3Развитие по этапам — 2–4 недели каждый. Условные маршруты, реестр договоров, пролонгации, связка с 1С — в порядке реальной необходимости.

Это ориентиры, а не смета: точная цифра появляется после разбора процесса. Подробнее про подход и вилки — на странице CRM и внутренние системы.

Как переехать с почты без остановки работы

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