Договор редко зависает из-за одного человека. Чаще процесс распадается на несколько параллельных переписок: менеджер отправил файл юристу, бухгалтер ждёт реквизиты, руководитель не видит новую версию, контрагент прислал правки в другом формате, а финальный файл лежит у кого-то в почте. В какой-то момент уже трудно понять, какая версия актуальна и кто должен сделать следующий шаг.
Согласование договоров нужно строить как управляемый маршрут, а не как пересылку файлов. Система должна хранить карточку договора, версии, участников, условия, этапы, сроки, комментарии, возвраты на доработку, финальное решение и связанную переписку. Тогда договор перестаёт быть документом в почте и становится объектом процесса.
Карточка договора
Перед маршрутом нужна карточка договора. В ней фиксируются контрагент, предмет, сумма, валюта, срок действия, тип договора, ответственное подразделение, инициатор, проект или заказ, связанные документы и текущий статус. Без карточки система будет согласовывать файл, но не управлять договором как бизнес-объектом.
Карточка помогает строить правила. Один договор идёт по короткому маршруту, потому что типовой, сумма небольшая, контрагент известен, условия не изменены. Другой требует юриста, финансового согласования, руководителя направления и проверки безопасности, потому что сумма выше лимита или появились нестандартные условия.
Маршрут согласования
Маршрут договора редко бывает одинаковым для всех случаев. Он может зависеть от суммы, типа контрагента, подразделения, предмета договора, наличия аванса, срока оплаты, штрафных условий, персональных данных, интеллектуальных прав или других рисков. Если эти условия не описаны, сотрудник каждый раз вручную вспоминает, кому нужно отправить документ.
В системе маршрут должен строиться по правилам. Часть этапов может идти последовательно: сначала юрист, затем финансы, затем руководитель. Часть — параллельно: несколько подразделений смотрят договор одновременно и оставляют замечания. Для срочных договоров может быть отдельный маршрут, но с понятным правом на ускорение, а не устное «согласуйте быстрее».
Версии и правки
Главная боль договоров — версии. Если файл называется `договор_финал_2_исправленный`, процесс уже потерял управляемость. Система должна хранить историю редакций: кто загрузил версию, какие правки появились, кто их принял, кто отклонил, какая версия ушла контрагенту и какая версия стала финальной.
Комментарии тоже должны жить рядом с договором. Если замечание осталось в мессенджере, через неделю его трудно восстановить. Если оно привязано к карточке, видно, почему пункт изменили, кто согласовал исключение и какие условия остались спорными. Это особенно важно для договоров, которые потом влияют на оплату, поставку, гарантию или сервис.
Статусы без тумана
Статус «на согласовании» не помогает управлять сроком. Договор может быть у юриста, у финансового директора, у инициатора на доработке, у контрагента, у руководителя на подписи или в архиве после завершения. Каждый статус должен показывать, где договор находится сейчас и какое действие нужно для движения дальше.
Хорошая система показывает ответственного за текущий этап, дату поступления, нормативный срок, просрочку и причину возврата. Руководитель видит не общий список договоров, а узкие места: какие документы зависли у одного подразделения, какие ждут контрагента, какие вернулись на доработку и какие готовы к подписанию.
Возврат на доработку
Договор не обязан идти только вперёд. Его можно вернуть инициатору, юристу, менеджеру или контрагенту. Но возврат должен быть действием в системе: причина, комментарий, срок исправления, новая версия и ответственный. Иначе договор уходит в переписку, а маршрут формально остаётся «открытым».
Здесь тема близка к согласованию заявок, но договор сложнее: у него есть версии текста, юридические условия, реквизиты, приложения, подписи, связь с заказом и последствия после заключения. Поэтому договорный процесс нельзя полностью сводить к общей задаче на согласование.
Роли и права
Договор содержит коммерческие условия, реквизиты, персональные данные, финансовые обязательства и иногда конфиденциальные приложения. Поэтому важно заранее определить права: кто видит договор, кто может менять карточку, кто загружает новую версию, кто согласует, кто отклоняет, кто имеет право подписать и кто может изменить маршрут.
Отдельно нужны замещения. Если согласующий в отпуске, договор не должен останавливаться на неделю. Система должна знать заместителя, период замещения и границы полномочий. Это снижает зависимость процесса от личных договорённостей и ручного контроля руководителя.
Связь с XRM
Для многих компаний договор — часть более широкого клиентского или проектного процесса. Он связан с контрагентом, сделкой, заказом, сервисным объектом, заявкой, оплатой и закрывающими документами. Поэтому договоры удобно вести внутри XRM-системы или связывать документооборот с XRM.
Так договор не живёт отдельно от бизнеса. Менеджер видит, какой договор относится к клиенту и заказу. Руководитель понимает, почему сделка не двигается. Исполнитель видит, какие условия уже согласованы. Финансы видят сроки оплаты и лимиты. Сервис видит гарантийные обязательства и приложения.
Интеграции
Согласование договоров часто требует обмена с другими системами. Из CRM или XRM приходит клиент и сделка. Из ERP или 1С — контрагент, реквизиты, лимиты, счета, статусы оплаты. Из ЭДО — внешний контур подписания. Из почты — входящие письма и вложения. Из электронного архива — финальные документы и приложения.
Если интеграций нет, сотрудники продолжают переносить данные вручную: копируют реквизиты, ищут актуальный файл, прикладывают договор к заказу, обновляют статус в другой системе. В этом месте появляются ошибки, дубли и потери времени. При индивидуальной разработке можно связать договорный маршрут с теми системами, где уже живут клиенты, заказы, финансы и документы.
Архив и поиск
После подписания договор не должен исчезать из процесса. Его нужно хранить вместе с карточкой, версиями, приложениями, дополнительными соглашениями, актами, сроками, ответственными и историей согласования. Тогда через полгода можно быстро понять, какие условия действуют и кто согласовал спорный пункт.
Для поиска важны метаданные: контрагент, тип, сумма, дата, срок действия, статус, проект, подразделение, предмет и ответственный. Если хранить только файлы в папках, поиск превращается в догадки по названию документа. Если договор хранится как структурированная карточка, система помогает находить документы по смыслу процесса.
Порядок внедрения
- Описать типы договоров и обязательные поля карточки.
- Определить правила маршрута: сумма, подразделение, тип контрагента, риск и нестандартные условия.
- Настроить роли, права, замещения и порядок изменения маршрута.
- Зафиксировать работу с версиями, комментариями и возвратом на доработку.
- Определить статусы и контроль сроков по каждому этапу.
- Связать договоры с клиентами, заказами, финансами, ЭДО и архивом.
- Проверить процесс на нескольких реальных договорах перед массовым запуском.
Типичные ошибки
- Автоматизировать хаос. Если правила маршрута не описаны, система просто переносит почтовую переписку в новый интерфейс.
- Согласовывать только файл. Без карточки договора теряются сумма, контрагент, сроки, связь с заказом и ответственность.
- Не управлять версиями. Несколько файлов с похожими названиями быстро приводят к спору о том, что было согласовано.
- Оставить статусы общими. «На согласовании» не показывает узкое место и не помогает ускорить договор.
- Не связать архив с процессом. Финальный документ должен храниться вместе с историей согласования, а не отдельно от неё.
Согласование договоров работает, когда договор движется по прозрачному маршруту: карточка, версия, согласующие, сроки, комментарии, решение, подпись и архив. Если в компании уже есть регулярные задержки, потерянные версии или споры по условиям, начинать стоит с карты процесса: какие договоры бывают, кто принимает решения и какие данные нужны каждому этапу.