Договорной процесс в 1С:Документообороте: как не перенести старый хаос в новую систему

Договорной процесс в 1С:Документообороте: как не перенести старый хаос в новую систему

Договорной процесс редко ломается громко.

Обычно он ломается тихо: один договор согласовали в почте, второй отправили юристу в мессенджер, третий лежит в сетевой папке с названием “Финальная_версия_финал_2.docx”, четвёртый подписали, но забыли положить в архив, пятый бухгалтерия не видит, шестой руководитель согласовал устно, а седьмой уже три недели “где-то на проверке”.

И всё это вроде бы работает. Люди привыкли. Инициатор знает, кому написать. Юрист знает, где искать последнюю версию. Руководитель просит прислать “коротко в личку”. Бухгалтерия ругается, но принимает. Архивариус периодически наводит порядок. А потом компания решает внедрить 1С:Документооборот.

На первой встрече звучит фраза:

“Нам нужно автоматизировать договоры. Только сделайте удобно, примерно как сейчас”.

Вот здесь и начинается главная развилка.

Можно действительно сделать “примерно как сейчас”: перенести старые этапы, старые роли, старые обходы, старые папки, старые привычки. В 1С появятся карточки договоров, маршруты, задачи, статусы. На презентации всё будет выглядеть солиднее.

Но через пару месяцев пользователи снова уйдут в почту и мессенджеры. Просто теперь рядом с этим будет ещё и 1С:Документооборот, куда нужно “для порядка” что-то заносить.

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

Иначе мы автоматизируем не процесс, а привычку выживать в хаосе.

 

 

Почему договорной процесс особенно болезненный

Договор — это не просто файл с текстом.

В 1С-практике договор почти всегда находится на стыке нескольких интересов:

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

Поэтому договорной процесс сложно “просто настроить”. Он затрагивает роли, права, НСИ, маршруты, файлы, версии, задачи, сроки, статусы, интеграции и регламенты.

Плохой признак, если на обследовании договорного процесса вся логика сводится к фразе:

“Сначала юрист, потом руководитель, потом директор”.

Это не процесс. Это только верхушка процесса.

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

 

Как договорный процесс обычно выглядит “до 1С”

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

В реальности часто получается иначе.

• Проект договора приходит от контрагента по почте.
• Инициатор пересылает его юристу.
• Юрист вносит правки в Word и отправляет обратно.
• Инициатор пересылает контрагенту.
• Контрагент присылает новую версию.
• Кто-то забывает включить режим правок.
• Руководитель согласует по скриншоту в мессенджере.
• Финансы подключаются слишком поздно.
• Подписанный скан кладут в папку.
• Оригинал ищут через месяц.
• Бухгалтерия спрашивает, где договор и кто его согласовал.

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

• “Стало дольше”.
• “Раньше я просто отправлял юристу”.
• “Теперь нужно слишком много полей”.
• “Задача ушла не тому”.
• “Я не понимаю, какая версия актуальная”.
• “Руководитель всё равно просит прислать в личку”.

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

 

Главная ошибка: начинать с маршрута согласования

Очень частый сценарий: заказчик просит настроить маршрут согласования договоров.

Аналитик открывает список вопросов и начинает уточнять:

• кто согласует;
• в каком порядке;
• какие сроки;
• что делать при возврате;
• кто утверждает.

Вопросы правильные, но если начать только с них, есть риск пропустить основу.

Маршрут — это не самостоятельный объект. Маршрут должен вытекать из логики договора.

Перед маршрутом нужно понять:

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

Если этого не сделать, маршрут будет похож на очередь из людей. А очередь из людей — это ещё не бизнес-процесс.

Хороший договорной маршрут отвечает не на вопрос “кого добавить?”, а на вопрос “кто какое решение принимает и на каком основании?”.

Мини-кейс 1. Юрист согласует всё подряд

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

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

Но дальше выясняется, что через юриста идут:

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

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

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

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

Иногда результатом автоматизации должен быть не “все договоры через юриста”, а “юрист смотрит то, где действительно есть юридический риск”.

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

 

Мини-кейс 2. Финансы подключаются после того, как всё уже согласовали

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

“А бюджет на это есть? А статья расходов какая? А период обязательств? А почему оплата авансом?”

Документ возвращается назад. Инициатор раздражён: “Почему раньше не сказали?”. Юрист раздражён: “Мы текст уже проверили”. Руководитель раздражён: “Я уже согласовал”.

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

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

Что стоит уточнить:

• есть ли сумма договора;
• есть ли лимиты согласования;
• нужно ли проверять бюджет;
• какие статьи расходов используются;
• есть ли связь с заявками на оплату;
• передаются ли данные в 1С:Бухгалтерию или ERP;
• кто отвечает за финансовую аналитику.

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

 

Мини-кейс 3. Финальная версия договора живёт в голове инициатора

Самая неприятная проблема договорного процесса — версии.

Договор прошёл несколько кругов согласования. Контрагент прислал свои правки. Юрист внёс замечания. Инициатор что-то поправил. Руководитель согласовал вариант “с учётом последних изменений”. Потом подписали файл, но через месяц никто не может уверенно сказать, это точно тот текст, который согласовывали?

В папке лежат файлы:

• Договор.docx;
• Договор_правки_юриста.docx;
• Договор_новый.docx;
• Договор_финал.docx;
• Договор_финал_контрагент.docx;
• Договор_подписанный.pdf.

И где здесь истина?

В 1С:Документообороте важно не просто хранить файл. Нужно договориться о правилах:

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

Если правила версий не описать, 1С станет просто новой папкой для старого бардака.

 

Как разложить договорной процесс на этапы

Я бы не начинала с большой красивой схемы. Лучше сначала разложить процесс на понятные этапы.

 

Этап	Что выяснить	Что может пойти не так
Инициирование договора	Кто создаёт договор, на каком основании, какие данные обязательны	Инициатор создаёт карточку без контрагента, суммы, вида договора или вложения
Подготовка проекта	Кто готовит текст, используется ли шаблон, откуда приходит проект	Версии начинают гулять между почтой, Word и папками
Проверка контрагента	Кто проверяет контрагента, какие данные нужны, есть ли стоп-факторы	Договор согласовали, а контрагент не прошёл проверку
Юридическая проверка	Что именно проверяет юрист, когда он обязателен, какие замечания фиксирует	Юрист становится обязательным этапом для всего подряд
Финансовая проверка	Сумма, бюджет, статья расходов, условия оплаты, лимиты	Финансы подключаются слишком поздно
Согласование руководителем	Кто принимает управленческое решение и от чего зависит уровень согласования	Руководитель согласует формально, не понимая своей зоны ответственности
Подписание	Кто подписывает, каким способом, где хранится подписанный файл	Подписывается не та версия или подписанный файл не возвращается в систему
Регистрация и хранение	Кто регистрирует, где хранится, кто видит, как искать	Договор есть, но найти его потом невозможно
Исполнение и контроль	Есть ли сроки, обязательства, оплаты, закрывающие документы	После подписания договор исчезает из управления

 

Эта таблица полезна на обследовании. Она быстро показывает, что договорной процесс — это не только согласование текста.

 

Что нужно спросить у заказчика

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

1. Виды договоров

• Какие виды договоров есть?
• Какие договоры самые частые?
• Какие самые проблемные?
• Есть ли типовые шаблоны?
• Чем отличается договор с клиентом, поставщиком, подрядчиком, физлицом?
• Есть ли дополнительные соглашения, спецификации, приложения?

2. Инициирование

• Кто может инициировать договор?
• На основании чего создаётся договор?
• Какие поля обязательны на старте?
• Можно ли запустить согласование без проекта договора?
• Что делать, если контрагент ещё не заведён в 1С?

3. Маршрут

• Кто согласует договор?
• От чего зависит маршрут?
• Есть ли лимиты по сумме?
• Когда подключается юрист?
• Когда подключаются финансы?
• Когда нужен директор?
• Есть ли параллельное согласование?
• Что происходит при возврате?

4. Версии и файлы

• Где появляется первая версия договора?
• Кто имеет право менять файл?
• Как фиксируются правки?
• Можно ли менять файл после согласования?
• Как определяется финальная версия?
• Где хранится подписанный экземпляр?

5. Права доступа

• Кто должен видеть договор?
• Кто должен видеть сумму?
• Кто должен видеть файлы?
• Есть ли конфиденциальные договоры?
• Как ограничивается доступ по организациям и подразделениям?
• Что происходит при увольнении сотрудника?

6. Интеграции

• Нужна ли связь с 1С:Бухгалтерией?
• Нужна ли связь с ERP?
• Используется ли ЭДО?
• Передаются ли реквизиты договора в другие системы?
• Где создаётся контрагент?
• Какая система является мастер-системой по договорам?

7. Контроль и отчётность

• Какие договоры считаются просроченными?
• Кто контролирует зависшие согласования?
• Какие отчёты нужны руководителям?
• Нужно ли видеть договоры без подписанного экземпляра?
• Нужно ли контролировать окончание срока действия?
• Нужно ли контролировать исполнение обязательств?

Хорошее интервью по договорному процессу — это не “кого поставить в маршрут”. Это разговор о том, как компания принимает обязательства и как потом эти обязательства контролирует.

 

Как плохо и как лучше

 

Как часто делают плохо	Как лучше
Настраивают один общий маршрут на все договоры	Разделяют маршруты по видам договоров, суммам, рискам и условиям
Добавляют всех согласующих “на всякий случай”	Для каждого этапа фиксируют, что именно проверяет участник
Юрист проверяет все договоры без исключения	Юрист подключается обязательно для рисковых, нестандартных и изменённых условий
Версии договора живут в файлах с разными названиями	Определяют правила рабочих, согласованных и подписанных версий
Возврат на доработку пишут свободным текстом “исправить”	Используют понятные причины возврата и обязательный комментарий
Права дают широко, чтобы “не мешало работать”	Разделяют доступ по ролям, организациям, подразделениям и конфиденциальности
После подписания договор просто лежит в карточке	Контролируют срок действия, закрывающие документы, оплаты и связанные процессы
Изменения маршрута делают по устной просьбе	Назначают владельца договорного процесса и фиксируют изменения

 

Роли в договорном процессе

В 1С:Документообороте важно не просто добавить людей в маршрут, а описать роли.

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

 

Роль	Что делает	Что важно зафиксировать
Инициатор	Создаёт карточку договора, прикладывает проект, заполняет данные	Какие поля обязательны и за какие данные он отвечает
Юрист	Проверяет текст, условия, риски, правки контрагента	Когда его участие обязательно и какие замечания он фиксирует
Финансовый контролёр	Проверяет сумму, бюджет, условия оплаты, статью расходов	Какие финансовые параметры влияют на маршрут
Руководитель	Подтверждает необходимость договора и принимает управленческое решение	За что именно он отвечает: бюджет, риск, целесообразность, полномочия
Подписант	Подписывает договор или отправляет на подписание	Как определяется подписант и что считается фактом подписания
Регистратор / архив	Регистрирует и контролирует хранение подписанного экземпляра	Где хранится финальный документ и как его искать
Владелец процесса	Принимает решения по правилам договорного процесса	Кто утверждает изменения маршрутов и регламента

 

 

Возврат на доработку: маленькая деталь, которая ломает процесс

Возврат договора — это нормальная часть работы. Ненормально, когда возврат превращается в загадку.

Инициатор получает задачу “доработать договор”. В комментарии написано: “Исправить”. Что исправить? Текст? Сумму? Контрагента? Файл? Реквизиты? Приложение? Условия оплаты?

После этого начинается переписка в мессенджере. И вот договорной процесс уже снова живёт вне 1С.

Я бы обязательно вводила понятные причины возврата:

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

Не нужно делать 40 причин возврата. Пользователи всё равно не будут аккуратно выбирать. Но 7–10 понятных причин уже помогают сильно.

 

Права доступа: “пусть все видят всё” работает недолго

На этапе внедрения часто хочется упростить:

“Давайте пока дадим доступ шире, потом разберёмся”.

Иногда это временно допустимо на тесте. Но в боевом договорном процессе такой подход опасен.

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

Что нужно проверить:

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

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

 

Интеграции: договор редко живёт только в 1С:ДО

Договорной процесс в 1С:Документообороте часто связан с другими системами.

• В 1С:Бухгалтерии может быть нужен элемент договора для учёта.
• В ERP договор может использоваться в закупках, продажах, заказах, оплатах.
• В ЗУП могут быть кадровые договоры и документы.
• В ЭДО может происходить обмен подписанными документами.
• В архиве могут храниться долгосрочные документы.
• В системе задач могут контролироваться связанные поручения.

Интеграция — это не только технический обмен. Для аналитика здесь важны вопросы:

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

На бумаге красиво: “после согласования договор передаётся в бухгалтерию”. В жизни боль начинается с вопросов: а если контрагент не найден? А если договор уже есть? А если изменили сумму? А если бухгалтерия не принимает договор без определённого реквизита?

 

 

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

 

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

 

 

Шаблон карточки договорного процесса

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

 

Поле	Что указать
Название процесса	Согласование и хранение договоров
Владелец процесса	Например: юридический отдел / договорной отдел / финансовый директор
Границы процесса	От создания проекта договора до хранения подписанного экземпляра
Основные участники	Инициатор, юрист, финансы, руководитель, подписант, архив
Виды договоров	Клиентские, поставщики, подрядчики, допсоглашения, рамочные договоры
Ключевые реквизиты	Организация, контрагент, вид договора, сумма, срок, ответственный, подразделение
Условия маршрута	Вид договора, сумма, новый контрагент, нестандартные условия, организация
Причины возврата	Нет файла, замечания юриста, неверная сумма, нет основания, нужен другой маршрут
Связанные системы	БП, ERP, ЭДО, архив, почта
Контрольные отчёты	Договоры на согласовании, просроченные, без подписанного экземпляра, истекающие
Риски	Версии файлов, права, НСИ, отсутствие владельца, согласование вне системы

 

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

 

Типовые ошибки при внедрении договорного процесса

Ошибка 1. Копировать старый процесс без анализа

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

Ошибка 2. Делать один маршрут на всё

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

Ошибка 3. Не описывать ответственность согласующих

Если человек получил задачу “согласовать договор”, но не понимает, что именно проверить, он либо зависает, либо нажимает “Согласовано” формально.

Ошибка 4. Не управлять версиями файлов

Это выглядит удобно ровно до первого спора о том, какую версию согласовали и какую подписали.

Ошибка 5. Забыть про финал процесса

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

Ошибка 6. Не назначить владельца процесса

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

Ошибка 7. Не обучить руководителей

Инициаторов обычно обучают. Руководителей и согласующих часто считают “и так разберутся”. Потом именно они согласуют в мессенджере, потому что в 1С им неудобно или непонятно.

 

План наведения порядка за 30 дней

Если договорной процесс уже живёт хаотично, не обязательно сразу начинать большой проект на полгода. Можно начать с 30-дневного наведения порядка.

Неделя 1. Разобрать текущий процесс

• Собрать 5–10 реальных договоров разных типов.
• Посмотреть, как они проходили согласование.
• Найти обходы через почту, мессенджеры и папки.
• Зафиксировать участников и проблемные места.
• Выделить самые частые виды договоров.

Неделя 2. Описать целевой процесс

• Разделить договоры на типовые группы.
• Описать роли участников.
• Согласовать условия маршрутов.
• Определить причины возврата.
• Описать правила версий и финального файла.

Неделя 3. Настроить и проверить пилот

• Настроить 1–2 ключевых маршрута.
• Проверить права доступа.
• Проверить заместителей.
• Прогнать реальные сценарии: обычный договор, возврат, новый контрагент, крупная сумма, новая версия файла.
• Собрать замечания пользователей.

Неделя 4. Запустить управляемо

• Подготовить короткую инструкцию для инициаторов.
• Подготовить короткую памятку для согласующих.
• Назначить ответственного за зависшие договоры.
• Определить правила изменения маршрутов.
• Через 2–3 недели после запуска разобрать первые ошибки и донастроить процесс.

 

 

Что показать руководителю

Руководителю не всегда нужно показывать все настройки 1С:Документооборота. Ему важнее увидеть управленческую картину.

Я бы показывала такие вещи:

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

Бизнесу не нужна “красивая автоматизация договора”. Бизнесу нужен контроль обязательств, сроков, рисков и ответственности.

 

Что показать пользователям

Пользователям важно не объяснять всю методологию договорного процесса, а показать, как им теперь работать.

Для инициатора:

• как создать карточку договора;
• какие поля заполнить обязательно;
• какой файл приложить;
• как запустить согласование;
• как увидеть статус;
• что делать при возврате.

Для согласующего:

• где увидеть задачу;
• что именно нужно проверить;
• как согласовать;
• как вернуть с замечанием;
• как посмотреть историю;
• как работать при замещении.

Для владельца процесса:

• как смотреть зависшие договоры;
• как анализировать возвраты;
• как инициировать изменение маршрута;
• как контролировать работу после запуска.

 

Вывод

Договорной процесс в 1С:Документообороте — это не просто маршрут согласования договоров.

Это способ компании управлять обязательствами: кто инициирует договор, кто проверяет условия, кто принимает риск, какая версия считается финальной, где хранится подписанный документ и как потом договор используется в учёте, оплатах, отчётах и управлении.

Главная проблема договорного процесса обычно не в инструменте. Главная проблема в том, как процесс живёт после релиза.

Если нет владельца, правил версий, понятных ролей, нормальных возвратов, контроля сроков, прав доступа и связи с другими системами, то 1С:Документооборот быстро становится ещё одним местом, куда пользователи заносят информацию “потому что надо”.

Хороший договорной процесс должен отвечать на простые вопросы:

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

Если система отвечает на эти вопросы — договорной процесс действительно стал управляемым.

Если не отвечает — мы просто перенесли старый хаос в новую оболочку.

Автоматизация договоров начинается не с кнопки “Согласовать”. Она начинается с честного разбора: кто в компании принимает обязательства, кто за них отвечает и где теряется контроль.