Как организовать договорную работу в компании: маршруты, роли и технологии

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

Олеся Запарина предлагает восстанавливать маршрут не по регламенту и не со слов одного сотрудника. Для разбора берут несколько недавно завершённых договоров и смотрят, что происходило с каждым из них.

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

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

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

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

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

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

Стандартные договоры с низким риском Алексей Никифоров предлагает направлять в «зелёный коридор». Юрист не проверяет каждый такой файл, если заранее установлены границы:

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

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

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

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

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

Возвращать обязательную проверку всех договоров в обоих случаях рано: сначала надо разобраться, почему не сработало правило.

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

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

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

В долгих проектах координацию можно передать контрактному менеджеру. Алексей Никифоров описывает эту роль через жизненный цикл договора: специалист следит за версиями, обязательствами, изменениями, приёмкой и передачей информации между участниками. Юрист при этом занимается правом и риском. Для потока коротких типовых договоров отдельная должность может не окупиться; координацию тогда закрепляют за инициатором, владельцем процесса или сотрудником Legal Operations.

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

• какой информации опять не хватило;
• почему договор снова пошёл не по тому маршруту;
• где участники по-разному поняли правило.

После такого разговора меняют конкретный элемент — форму заявки, шаблон или границу ответственности. Именно из этих деталей складывается опыт внутреннего клиента юридической функции.

После разбора маршрутов становится понятнее, что поручить системе:

• назначать согласующих;
• хранить версии;
• передавать данные в ЭДО;
• проверять договор по заданным правилам.

Выбор зависит от конкретного сбоя, а не от количества функций в презентации поставщика.

Перед внедрением Егор Трубников предлагает проверить три вещи:

1. Готовы ли люди работать по новым правилам.
2. Достаточно ли упорядочен сам процесс.
3. Подходит ли технология для выбранной задачи.

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

Егор Трубников приводит пример из практики команды. До массового распространения больших языковых моделей она обучала собственный инструмент автоматической проверки на договорах компании, формах, чек-листах и внутренних правилах. Затем появились технологические подходы, которые позволяли решать похожие задачи проще и быстрее. Разработку всё равно продолжали поддерживать: в неё уже вложили много времени и сил. В итоге инструмент почти не использовали.

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

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

Для задач, связанных с качеством, одного срока недостаточно.

Без исходных данных после пилота останутся только впечатления: одним пользователям инструмент покажется быстрым, другим — неудобным, но сравнить результат будет не с чем.

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

Каждую из этих задач надо тестировать отдельно. Решение по договору и ответственность за него остаются внутри компании.

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

Для начала достаточно взять распространённый тип договора и выбрать сбой, который повторяется.

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

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

После этого станет понятно, нужна ли новая форма заявки, другой маршрут, зелёный коридор или технологический инструмент.

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