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

Зачем нужна система: типичные боли договорной работы

Когда договоры согласуют в почте и мессенджерах, сначала кажется, что это быстро. Потом цепочки писем разрастаются, файлы превращаются в «финал_2», а комментарии юристов остаются в переписке, где их сложно найти.

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

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

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

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

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

Из чего состоит система договорной работы

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

Основные элементы

Маршруты согласования. У каждого договора должен быть понятный путь: инициатор, юрист, безопасность (если нужно), финансовая служба, руководитель. Важна и история решений: кто согласовал, кто вернул на доработку и с каким комментарием. Это снимает споры в стиле «я не видел» и помогает быстро восстановить логику изменений.

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

Управление сроками. Это не только даты подписания и окончания, но и уведомления о продлении, контроль ключевых этапов и обязательств. Напоминания работают лучше, когда привязаны к конкретному действию: подготовить допсоглашение, запросить акт, выставить счет, закрыть этап.

Единый реестр договоров и реестр обязательств. Реестр договоров отвечает на вопрос «что у нас есть», а обязательства - «что мы должны сделать и что должны нам». Например, при закупке партии рабочих станций для филиалов удобно видеть не только договор, но и график поставок, приемку, гарантийные обязательства и платежи.

Отчетность, которую реально используют

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

Маршруты согласования: как настроить понятно и без лишнего

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

Какие маршруты бывают и когда они удобны

Обычно используют три схемы:

• последовательная - когда важно пройти этапы по порядку (инициатор, юрист, финансы, руководитель);
• параллельная - когда несколько служб могут проверять договор одновременно (например, юрист и ИБ);
• смешанная - наиболее частая: часть согласований идет параллельно, а финальное утверждение всегда остается последним шагом.

Чтобы это работало вживую, задайте правила запуска маршрута. Они должны быть понятными и проверяемыми: по типу договора, сумме, подразделению, контрагенту. Например: если договор поставки выше порога X - добавляем финансового директора; если это ИТ-услуги - подключаем ИБ; если контрагент новый - включаем проверку комплаенс. Тогда маршрут собирается автоматически, без ручной импровизации.

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

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

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

Контроль лимитов: чтобы договор не выходил за рамки бюджета

Контроль лимитов нужен, чтобы договор не превращался в сюрприз для финансовой службы. Лимит - это не только общий бюджет. Чаще всего он задается связкой параметров: статья затрат, проект, ЦФО, период (месяц, квартал, год), иногда контрагент или тип закупки. Чем точнее логика лимита, тем меньше ручных разборов потом.

Удобно начинать с простого набора правил и усложнять по мере зрелости процесса. Например, закупка серверов для дата-центра может проверяться по проекту и ЦФО, а типовые услуги (связь, уборка) - по статье и периоду.

Где проверять лимит

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

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

Что делать, если лимит превышен

Реакция зависит от политики компании. На практике встречаются три рабочих сценария: жесткая блокировка подписания при превышении, согласование исключения (с причиной и ответственным) или перенос части оплаты/объема на следующий период. Пересмотр бюджета тоже возможен, но как плановая корректировка, а не как обход правил.

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

Уведомления о сроках: как не пропускать важные даты

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

Сначала определите, какие даты критичны именно для вас. Обычно это не только подписание и срок действия. В реальной работе важны даты поставки по этапам, контрольные точки приемки, крайний срок оплаты, а также окно для пролонгации или расторжения.

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

Хорошая схема держится на трех уровнях: заранее (например, за 30/14/7 дней), в день срока и после срока (просрочка). Чтобы уведомления не превращались в спам, задайте частоту и приоритеты: одно «тихое» напоминание заранее и одно «громкое» в день срока, а просрочку эскалировать только если ее не закрыли.

Пример: договор на поставку партии рабочих станций. За 14 дней уведомление получает исполнитель (готовность поставки) и финансы (план платежа). В день срока поставки - исполнитель и ответственный за приемку. Если просрочка держится 3 дня, дополнительно уведомляется руководитель, а риск фиксируется по обязательству.

Реестр обязательств: как держать исполнение под контролем

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

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

Важно связать обязательства с подтверждениями: платежами, поставками, актами, счетами. Тогда видно не только «должны», но и «что уже подтверждено документами». Например, при закупке партии серверов для дата-центра удобно разделить обязательства на поставку по накладным и ввод в эксплуатацию по акту и сразу понимать, где задержка - в логистике или в приемке.

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

Роли, доступы и прозрачность: кто что видит и кто отвечает

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

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

Рабочие правила обычно такие: суммы и лимиты видят финансы, руководитель и назначенные согласующие; вложения с коммерческими условиями - участники закупки и юрист; персональные данные - по принципу «минимально необходимого»; правка текста ограничена стадиями (черновик правит инициатор, после правок юриста финальную редакцию ведет юрист).

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

Отдельный блок - версии документов. Нужны понятные правила хранения: единый реестр, поиск по номеру, контрагенту и сумме, обязательная фиксация версий (что изменилось и кто утвердил). Тогда через полгода можно быстро найти подписанный вариант и объяснить, почему в договоре оказалась именно эта редакция.

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

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

1) Зафиксируйте, как все происходит сейчас

Соберите 10-20 последних договоров каждого типа и разложите их по фактам: кто инициировал, кто согласовал, где были задержки, какие правки повторялись. Важно описать реальные маршруты, а не то, как «должно быть по регламенту».

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

2) Настройте систему под простые сценарии

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

Запустите пилот на 1-2 подразделениях. Лучше выбрать команды с большим количеством типовых договоров: закупки, продажи, аренда. Через 2-3 недели станет видно, где узкие места: кто чаще всего задерживает согласование, каких полей не хватает, какие уведомления раздражают.

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

Частые ошибки и ловушки при автоматизации договоров

Первая ловушка - попытаться «оцифровать» хаос. Если раньше договоры жили в почте, а правила были в головах сотрудников, система начнет быстрее воспроизводить те же ошибки.

Часто проблемы начинаются с маршрутов: их делают слишком подробными (12 шагов, десятки условий, исключения на исключениях). В итоге люди ищут обходные пути, а скорость падает. Простая проверка: если новый сотрудник не понимает маршрут за 10 минут, он слишком сложный. Оставляйте только то, что реально снижает риски.

Еще одна боль - нет владельца процесса. Когда непонятно, кто отвечает за правила, справочники и спорные случаи, каждый отдел начинает жить по своим нормам. Появляются разные статусы («на визировании», «на согласовании», «в работе»), разные карточки контрагентов, и отчеты перестают сходиться.

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

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

Отдельная ловушка - когда реестр обязательств живет в Excel и не совпадает с договором. Так бывает у компаний с регулярными поставками и сервисом: договор подписан, а поставки и платежи ведутся отдельно, и в конце месяца появляются сюрпризы. Лучше, когда обязательства, суммы и сроки берутся из договора и меняются вместе с допсоглашениями.

Короткий чеклист: что проверить перед запуском

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

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

Отдельно проверьте отчетность: за 2-3 клика должны получаться списки просроченных обязательств и договоров с риском срыва сроков, без ручной сборки в Excel.

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

Пример на практике и следующие шаги

Представим сценарий: отдел закупок готовит договор на поставку оборудования. Сумма 9,8 млн тенге при лимите 10 млн, срок поставки 30 дней, оплата - после приемки. Нужно согласование юристов и финансов, затем подпись руководителя.

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

Если на этапе уточнений сумма меняется на 10,4 млн, маршрут переключается: добавляется согласование исключения. Финансовый директор подтверждает превышение лимита, руководитель подразделения дает обоснование (почему нельзя купить дешевле или разбить поставку). После этого договор возвращается к финконтролю, чтобы зафиксировать обновленные условия.

Уведомления снимают необходимость жить в ручных напоминаниях. Обычно достаточно трех типов: заранее перед окончанием срока действия (чтобы успеть продлить или закрыть), перед плановой датой платежа (чтобы проверить документы и лимит), а также в день просрочки, если акт или счет не загружен вовремя.

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

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

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