Подготовка к автоматизацииконтрактного менеджментав компании

Для кого этот стандарт

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

Стандарт будет полезен в трёх ситуациях:

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

Как использовать стандарт

Стандарт описывает два состояния подготовки к автоматизации:

• Текущее состояние (AS IS) — как компании чаще всего готовятся к автоматизации сегодня: без структурированной диагностики, на основе демо вендора, интуиции и мнения нескольких сотрудников. Это помогает узнать типичные ошибки в своей практике.
• Целевое состояние (TO BE) — как построить подготовку методически: с диагностикой процесса по стримам, зафиксированными метриками успеха, экономическим обоснованием и осознанным выбором технологии.

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

Мы описали методологию на основе практики Doczilla и её клиентов. Большинство практик применимо независимо от того, какого вендора и какую технологию компания в итоге выберет.

Аудит готовности к автоматизации

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

Пройти тест

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

Цена ошибки при недооценке процесса

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

Показательный кейс — внедрение конструктора документов в одной из крупных промышленных компаний. Команда подошла к делу основательно: собрала требования у всех, кто причастен к договорной работе, объединила технические задания нескольких потенциальных вендоров и получила документ на 57 страниц с 425 функционально-техническими требованиями. Логика понятна: чем больше требований предъявишь вендору, тем меньше риск, что чего-то не хватит.

Через несколько лет использования системы выяснилось, что реально актуальны только 43% этих требований — остальные 57% функциональности, на которую ушли месяцы разработки и согласований, простаивали без дела. Приёмка проекта заняла больше месяца ежедневных встреч по восемь часов: со стороны компании в приёмке участвовало множество стейкхолдеров с разным видением, и по каждому из 425 пунктов находилось замечание.

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

Что бывает, если пропустить диагностику

Что считается «автоматизацией»

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

Кто участвует в подготовке со стороны компании

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

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

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

• Описываете пользовательский путь AS IS (как сделка идёт сейчас)
• Проектируете пользовательский путь TO BE (как будет после автоматизации)
• Делаете расчёт метрик успеха проекта и экономического эффекта
• Собираете карту стейкхолдеров, от которых зависит проект

Подробнее об артефактах и распределении ответственности рассказываем в разделе 2.2.

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

2.1 Два формата обследования: экспресс и полное

Обследование бывает двух видов. Граница между ними — глубина погружения и результаты на выходе.

Кто отвечает за обследование

2.2 Артефакты на выходе и кто за них отвечает

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

Для полного обследования к этому списку может добавляться пятый артефакт — техническое задание, если проект идёт через тендер или того требует внутренний регламент закупки. Ответственный за его подготовку определяется отдельно и, как правило, подключает к работе юристов, ИТ-архитектора и вендора-кандидата.

2.3 Подготовка к интервью: контекст компании, ЛНА, опросники

Подготовка занимает 2–3 часа, но сильно увеличивает шанс, что интервью пройдут результативно, а не превратятся в пересказ регламента.

Что нужно выяснить до первой встречи

Локальные нормативные акты (ЛНА)

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

ЛНА дают формальную картину процесса. Она почти всегда отличается от того, как процесс устроен на самом деле. Сравнение «как должно быть по регламенту» и «как происходит в жизни» — главный источник зацепок для интервью.

Ознакомьтесь с ЛНА до первого интервью — это позволяет глубже погрузиться в контекст респондентов и говорить с ними в терминах, которые им знакомы.

Что иметь под рукой на встрече

• Опросник, соответствующий роли респондента (для инициаторов, юристов, ОЦО, ИТ — вопросы для каждой роли различаются, поскольку они видят процесс с разных сторон)
• Список ключевых вопросов из ЛНА, требующих уточнения
• Несколько примеров из других проектов — на случай, если нужно показать, как аналогичная задача решена в похожей компании

Опросники для интервью по ролям

Ниже — опросники для интервью по четырём ролям. Для инициаторов и юристов приведены полные опросники из практики Doczilla; для ОЦО и ИТ — стартовый список, который можно расширить по тому же принципу. Перед каждой встречей запросите и изучите ЛНА компании, которые регулируют процесс заключения сделок, если вам их предоставят: это экономит время интервью и помогает говорить с респондентом на одном языке.

Часть вопросов ветвится по сценарию — какой вариант применим, лучше понять заранее по ЛНА или в начале разговора; возможны и несколько вариантов одновременно. Это не жёсткий сценарий: дополняйте и убирайте пункты под конкретный стрим. Приёмы, которые помогают довести разговор до реальных болей, а не пересказа регламента, — в разделе 2.5.

Инициаторы

Закупки · Продажи · Логистика · Другие бизнес-подразделения — функция в процессе: инициация создания договора.

Роль и нагрузка

• Расскажите о своей роли. За что вы отвечаете в компании?
• Какие типы договоров или иных документов вы инициируете?
• Как часто вы инициируете договоры — сколько в месяц?
• Были ли случаи, когда договор нужно было подготовить срочно, за 1–2 дня? Как вы организовывали процесс и с кем взаимодействовали?

Формирование и передача запроса

• Опишите весь путь договора и своё участие в нём. На какие этапы вы бы разделили существующий договорный процесс? Одинаков ли путь для всех видов договоров, допсоглашений и сделок разного масштаба? Какие есть типовые сценарии?
• Сколько времени занимает каждый этап? На каком этапе вы лично теряете больше всего времени? Есть ли SLA по согласованию и какие ошибки встречаются чаще всего?
• Что служит сигналом для начала работы над договором? Кто принимает это решение?
• Бывает ли, что вместе с договором нужно подготовить сопутствующие документы: акт, спецификацию, приложения? Как вы делаете это сейчас? Кто отвечает за их корректность — вы или юрист?
• Откуда вы берёте данные для запроса и заполнения договора — из каких систем, писем, таблиц, старых договоров? Что копируете вручную? Откуда берутся реквизиты контрагента и данные для приложений?

Дальше сценарий зависит от того, кто готовит договор, — уточните это по ЛНА заранее или в начале разговора. Возможны несколько вариантов одновременно.

Вариант А. Договор готовит сам инициатор по утверждённому шаблону

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

Вариант Б. Договор готовит не инициатор — МО, ОЦО или юрист

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

Вариант В. Форма договора определяется в зависимости от контрагента

• Кто решает, по чьей форме работаем — вашей или контрагента — и как принимается это решение?
• Что происходит, если контрагент настаивает на своей форме?
• Участвует ли контрагент в заполнении формы или анкеты? Кто и из каких источников берёт его реквизиты и другие данные?

Участие после инициации

• После подготовки первого драфта на каких этапах вы ещё участвуете в работе над договором?
• Насколько вам понятно, что происходит с договором после того, как вы его передали? Знаете ли вы, кто его согласовывает и на каком он сейчас этапе?
• Бывает, что договор возвращается к вам на уточнение, — как часто и по каким причинам? Через какой канал?
• Какие системы вы используете в работе с договорами — CRM, ERP, почта, мессенджеры, общие папки, Confluence, что-то ещё?
• Есть ли данные, которые приходится вносить повторно в разных системах? Например, реквизиты контрагента — вбиваете один раз или в нескольких местах?
• Были ли случаи, когда договор подписали с ошибкой или неактуальными данными? Чем это закончилось?

Боли и пожелания — самый важный блок

• Если бы вы могли изменить только одну вещь в договорном процессе — что бы это было?
• Что ещё хотели бы улучшить?
• Что вам нравится в текущем процессе и что не хотели бы менять?
• С кем ещё стоит поговорить? Кто в компании больше всего заинтересован в улучшениях, а кто, наоборот, настроен скептически?

Юристы

Юридический департамент — функция в процессе: подготовка и/или согласование договоров.

Роль и нагрузка

• Расскажите о своей роли. За какие типы договоров вы отвечаете?
• Сколько договоров проходит через вас в месяц? Какова доля типовых и нестандартных?
• Какие функции вы выполняете в процессе: разработка шаблонов, подготовка договоров под задачи инициаторов, согласование готовых договоров, работа с правками контрагентов? (можно несколько)

Шаблоны и типовые формы

• Сколько актуальных шаблонов договоров сейчас поддерживается? Кто отвечает за каждый шаблон?
• Где физически хранятся шаблоны — в одном месте или в разных источниках?
• Как пользователи находят нужный шаблон? Понимают ли они, какой именно нужен: по виду договора или по другим параметрам?
• Как пользователи узнают, что шаблон обновился? Когда в последний раз была ситуация, что кто-то работал с устаревшей версией?
• Опишите процесс создания и обновления шаблона: кто инициирует, кто разрабатывает, кто утверждает, как публикуется новая версия. Сколько времени занимает каждый этап?
• Есть ли чек-листы или гайды для бизнеса по допустимым отклонениям от типовых условий?
• Бывает ли, что изменение одного шаблона требует обновления других? Как такие зависимости выявляются?

Подготовка договора: уточните сценарий по ЛНА заранее или в начале разговора — возможны несколько вариантов одновременно.

Вариант А. Юрист сам готовит договор по запросу инициатора

• Как поступает запрос на подготовку? Через какой инструмент? Есть ли стандартная форма?
• Какую информацию инициатор передаёт вместе с запросом? Обычно её достаточно?
• Какой шаблон используете и где его берёте?
• Как часто приходится возвращаться к инициатору за уточнениями? По каким вопросам?
• Сколько времени занимает подготовка одного договора?

Вариант Б. Юрист проверяет договор, который подготовил инициатор, ОЦО или отдел оформления договоров

• Как получаете договор на проверку — от кого, через какую систему?
• Что именно проверяете — весь договор или конкретные разделы и поля?
• Проверяете ли, что использован актуальный типовой шаблон? Как именно?
• Какие самые частые причины отклонения или возврата на доработку?
• В каком формате передаёте замечания — комментарии в файле, письмо, задача?
• Получив исправленный документ, проверяете его целиком заново или только исправления?

Вариант В. Юрист работает с входящими договорами — контрагент присылает свою форму

• Какова доля входящих договоров от общего объёма?
• На что обращаете внимание в первую очередь?
• Есть ли у вас правила, по которым вы проверяете такой договор? Какие положения обязательно нужно проверить — или каждый раз полагаетесь на опыт?

Внутреннее согласование

• Опишите путь договора от инициатора до поступления к юристу и завершения согласования. Сколько времени занимает каждый этап? Где он чаще всего застревает?
• Согласование последовательное или параллельное? Обсуждаете ли спорные пункты с другими согласующими или каждый работает изолированно?
• Как устроена совместная работа — где и в каком формате фиксируются замечания, как обсуждаются спорные вопросы?
• Какие договоры не требуют согласования юристом? Бывает, что согласование не требуется по правилам, но вас всё равно привлекают?
• Что происходит после согласования? Кому передаёте договор? Где фиксируется, что он согласован?

Согласование правок с контрагентами

• В каком виде контрагент присылает правки — протокол разногласий, свою редакцию, письмо? Через какой канал — почта, ЭДО, портал?
• Правки приходят к вам напрямую или сначала к ОЦО или инициатору?
• Каков средний срок согласования с контрагентом — от первой отправки до договорённости? Сколько времени занимает одна итерация?
• Согласовываете ли спорные пункты внутри компании? С кем именно?
• Есть ли стандартный набор повторяющихся вопросов от контрагентов? Ведётся ли база готовых ответов и аргументов?
• Как принимаются решения по правкам от контрагента — что принять, что отклонить? Есть ли матрица рисков или матрица допустимых отклонений от типовых условий, по которой это определяют?

Системы и данные

• Какие системы вы используете в работе с договорами — СЭД, ЭДО, СУПР, 1С, SAP, Confluence, почта, мессенджеры, общие папки, что-то ещё?
• Есть ли данные, которые приходится вносить повторно в разных системах? Например, реквизиты контрагента, предмет, цена договора, другие параметры сделки?
• Есть ли интеграции между этими системами или данные синхронизируют вручную?

Качество и риски

• Бывали ли ситуации, когда после подписания договор пришлось корректировать? Какая типичная причина?
• Планируются ли изменения в процессе согласования договоров в вашем департаменте или в компании в целом?

Боли и пожелания — самый важный блок

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

ОЦО

• Какие данные вы вручную переносите из одного документа или одной системы в другую при обработке договора?
• Когда в последний раз вы находили ошибку в реквизитах уже после того, как договор ушёл на подписание? Что произошло дальше?
• Сколько времени в среднем занимает обработка одного договора на вашей стороне?
• В каких системах вы работаете с договором — учётная система, документооборот, таблицы, почта?
• Как вы понимаете, что договор готов к следующему шагу: есть чёткий сигнал или приходится уточнять?
• Какая часть вашей рутинной работы с договорами отнимает больше всего времени, но не требует именно вашей экспертизы?
• Если бы вы могли автоматизировать только одну операцию, какую бы выбрали?

ИТ

• В каких системах сейчас живут данные о договорах и контрагентах — учётная система, документооборот, CRM?
• Есть ли между этими системами интеграция или данные переносятся вручную?
• Какие у компании требования к информационной безопасности при работе с ИИ — можно передавать тексты договоров во внешние модели или нет?
• Кто в компании отвечает за архитектуру интеграций и сможет участвовать в проекте?
• Есть ли ограничения по размещению данных — например, требование хранить всё on-premise?
• Какие API или каналы обмена данными уже есть у систем, которые нужно будет связать?
• Что технически мешало предыдущим попыткам автоматизации, если они были?
• Как сейчас контролируется, кто и когда получил доступ к конкретному договору?

Фиксируйте ответы сразу в формате «что происходит → почему это узкое место → к чему приводит» (раздел 2.5) — так каждый ответ сразу превращается в материал для AS IS, а не остаётся просто цитатой.

2.4 Деление договорного процесса на стримы

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

Что такое стрим

Стрим — это связка «тип сделки + категория контрагента + способ инициации» со своим набором участников, шаблонов и узких мест.

Признаки самостоятельного стрима:

• свой ответственный юрист или своя группа шаблонов;
• своя цепочка согласования;
• свой инициатор или категория инициаторов.

Три правила деления

Делите по типам сделок, а не по подразделениям. «Закупки», «Продажи», «HR-договоры» — удобная категоризация для организационной структуры, но не для проекта автоматизации. У одного подразделения может быть три разных типа сделок с тремя разными процессами.

Правильно: «Закупки ТМЦ по типовому договору», «Закупки услуг по нетиповому договору», «Закупки по 223-ФЗ» — три отдельных стрима, даже если все они относятся к одному подразделению.

Используйте матрицу 2×2. В большинстве случаев типы сделок укладываются в матрицу «типовая/нетиповая сделка» × «своя форма / форма контрагента».

Держите минимум 5–10% объёма на стрим и максимум пять стримов. Если тип сделок занимает 1–2% от общего объёма — упомяните его как исключение в смежном стриме, не выделяйте отдельно. Если стримов получается больше пяти — попробуйте объединить близкие по логике.

Карта стримов

После первого интервью и анализа ЛНА должна получиться таблица — это первый артефакт, который стоит согласовать с ЛПР, до того как приступать к описанию AS IS.

2.5 Пользовательский путь AS IS: структура описания, извлечение и фиксация болей

Это описание текущего процесса по каждому стриму. Не схема в нотации BPMN (Business Process Model and Notation — международный графический стандарт для моделирования бизнес-процессов) с пятью уровнями вложенности, а рабочий документ, который отвечает на четыре вопроса: как устроено сейчас, где болит, сколько это стоит времени, какие данные перетекают между системами.

Структура описания одного стрима

Как извлекать боли — главный навык на интервью

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

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

От гипотетического к конкретному. Вопрос «Случалось ли работать с устаревшей версией шаблона?» почти всегда получает ответ «Да, иногда» — и на этом ответе ничего не построить.

Вместо этого: «Когда в последний раз это случилось? Расскажите, что произошло». Теперь есть конкретный случай с цифрами и последствиями.

Только одна вещь. Вопрос «Что бы вы хотели улучшить» вытягивает список из десяти пунктов, ни один из которых не приоритетен. Вопрос «Если бы вы могли изменить только одну вещь, что бы это было?» сразу выявляет самую сильную боль.

Покажите, не расскажите. Когда респондент рассказывает про процесс, стоит попросить показать его вживую: «Можно я посмотрю, как вы заполняете шаблон прямо сейчас?» За 10 минут наблюдения можно увидеть больше реальных проблем, чем за час словесного описания. Особенно хорошо этот приём работает с конечными пользователями.

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

Как фиксировать боли

Не записывайте боли просто списком. Используйте формат «что происходит → почему это узкое место → к чему приводит». Из боли, зафиксированной в таком формате, вырастают и TO BE, и метрика, и строчка в расчёте экономического эффекта.

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

2.6 Пользовательский путь TO BE: принцип «Каждое изменение закрывает конкретную боль» и уровень детализации

На этапе подготовки к автоматизации TO BE — это не техническое задание. Это верхнеуровневая схема процесса с учётом будущей технологии, рядом с которой явно написано, какие боли из AS IS закрываются и за счёт чего именно.

Что должно быть в TO BE по каждому стриму

Главный принцип: каждое изменение закрывает конкретную боль

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

Правильный подход — включать в TO BE только ту функциональность, которая закрывает боль, уже названную в AS IS. Каждый элемент TO BE должен ссылаться на конкретную боль из предыдущего раздела.

Уровень детализации

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

2.7 Метрики успеха и метрики завершения проекта

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

Два типа метрик

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

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

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

Откуда берутся формулировки метрик

Метрики не придумываются — они выводятся из уже зафиксированных болей по трёхшаговому алгоритму. Если пропустить методичную проработку TO BE (раздел 2.6) и сразу писать целевые формулировки метрик, велик риск завысить ожидания от технологии — например, пообещать «0 минут на проверку юристом» там, где на самом деле нужна проверка. Каждая метрика должна быть обеспечена конкретным решением из TO BE, а не желаемой цифрой. Если под метрикой нет технологического обоснования — вернитесь к разделу 2.6 и сначала спроектируйте, за счёт чего цель достижима.

1. Берём боль из AS IS по типовой сделке — именно такие договоры в целевом состоянии не должны проверяться юристом: все формулировки в них уже согласованы заранее, и отклонений от шаблона нет. Например: «20 минут × 200 договоров = 67 часов в месяц уходит на проверку соответствия шаблону».

2. Формулируем целевое состояние, которое можно обеспечить технологически. Например: «документ формируется без ошибок, юрист не вычитывает его вручную — экономия 67 часов в месяц».

3. Получаем метрику: «время юриста на проверку соответствия шаблону: 0 минут по типовым сделкам без отклонений (экономия 67 часов в месяц) к концу первого квартала после запуска».

Типовые категории метрик в договорной работе

Шаблон фиксации

2.8 Расчёт экономического эффекта

Без расчёта экономики обследование выглядит как набор благих намерений. С расчётом — это инвестиционный кейс, который можно защитить перед бюджетным комитетом или финансовым директором. Разница между «внедрение поможет команде работать удобнее» и «проект возвращает компании 80 миллионов рублей в год при стоимости внедрения 20 миллионов» — это разница между отклонённым и одобренным бюджетом.

Из чего складывается эффект

Откуда брать цифры

Шаблон представления

Под таблицей стоит дать короткий комментарий: «Стоимость проекта — 4,2 млн руб. Окупаемость — менее 3 месяцев. Цифры рассчитаны на основе консервативных оценок и ставок. Детальный расчёт — в приложении».

2.9 Карта стейкхолдеров

Карта стейкхолдеров — внутренний рабочий инструмент команды, которая готовит проект. С ЛПР или вендором она не согласуется. Цель — знать всех, кто влияет на решение о старте и на приёмку проекта, а не только формального ЛПР.

Кого нужно знать

Шаблон карты

Признаки, что карту пора дополнить

• Известен только координатор проекта, а вся остальная информация о процессе поступает через него в пересказе
• Спонсор и ЛПР — одно и то же лицо. Иногда это действительно так, но такое совпадение стоит перепроверить отдельно
• В карте нет внутреннего чемпиона
• Противники изменений не выявлены — это, как правило, значит не то, что их нет, а то, что их пока не нашли
• Не проведено ни одного интервью с конечным пользователем

2.10 Согласование результатов с ЛПР

AS IS, TO BE, метрики успеха и расчёт экономического эффекта нужно согласовать с ЛПР до того, как проект получит финальное одобрение на старт. Это критическая точка обследования: если ЛПР не подтвердил результаты, на этапе внедрения переделывать материалы будет дорого — и репутационно тяжело для команды, которая готовила проект.

Формат согласования

1. Презентация на 30–40 минут — контекст → AS IS с болями → TO BE с закрытием болей → метрики и экономический эффект.

2. Отправка письменных материалов после встречи — все четыре артефакта в финальном виде.

3. Получение подтверждения от ЛПР в письменном виде — короткое «согласовано» в переписке или отдельное письмо.

Что делать, если ЛПР не подтверждает результаты

Если после презентации ЛПР сомневается, не спешите пересматривать AS IS или TO BE целиком — чаще всего сомнение указывает на конкретный пробел, а не на ошибку во всей методологии.

2.11 Как обосновать полное обследование руководству

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

Возражения и что за ними стоит

Аргументы, которые работают

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

Стоимость ошибки. Можно начать проект и без обследования, но тогда компания принимает на себя риск: наша практика показала, что существенное изменение требований после старта разработки увеличивает стоимость проекта на 15–30%. Обследование стоит значительно меньше этого риска — а если проект дальше идёт с тем же вендором, его стоимость нередко засчитывается в счёт основного контракта.

Что компания получает на руках после полного обследования:

• AS IS с зафиксированными болями — внутренняя аналитика, которой раньше не было
• TO BE — карта изменений, понятная руководству и не требующая специальных знаний для чтения
• Концепт интеграций — техническое решение, с которым не нужно начинать с нуля даже при смене вендора
• Метрики эффекта и обоснование окупаемости — материал для бюджетного комитета
• Чек-лист готовности — что нужно сделать внутри компании до старта проекта (см. раздел 2.14)

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

2.12 Когда эскалировать проблему

Не всё в обследовании зависит от команды, которая его проводит внутри компании. Часть проблем решается только с участием руководства — спонсора проекта или ЛПР более высокого уровня, чем тот, с кем идёт работа изо дня в день. Если вы столкнулись с одной из ситуаций ниже — это повод не решать проблему в одиночку, а поднять её выше по управленческой вертикали своей компании.

2.13 Типичные ошибки при обследовании

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

2.14 Чек-лист завершённости обследования

Если все пункты закрыты — обследование завершено, и можно переходить к следующему шагу подготовки: экономическому обоснованию перед бюджетным комитетом (глава 3) и выбору технологического партнёра (глава 4). Если что-то не закрыто, лучше задержать переход на неделю, чем добирать недостающее уже в разгар проекта.

• Карта стримов составлена и согласована с ЛПР (раздел 2.4)
• AS IS описан по каждому стриму: этапы, боли, системы, цифры (раздел 2.5)
• TO BE спроектирован по каждому стриму: целевая схема, закрытие болей, технологии (раздел 2.6)
• Метрики успеха сформулированы — измеримые, с цифрами и датами (раздел 2.7)
• Каждая метрика привязана к конкретной боли из AS IS (раздел 2.7)
• Экономический эффект рассчитан и обоснован (раздел 2.8)
• Карта стейкхолдеров заполнена: ЛПР, спонсор, внутренний чемпион, конечные пользователи, противники изменений (раздел 2.9)
• Проведены интервью с конечными пользователями — минимум одно на стрим (раздел 2.5)
• AS IS, TO BE и расчёт эффекта согласованы с ЛПР письменно (раздел 2.10)
• Ограничения информационной безопасности выяснены и зафиксированы — нет блокирующих рисков, особенно в части использования ИИ (глава 5)

Базовая методика расчёта эффекта уже описана в разделе 2.8 — оттуда берутся цифры для конкретных стримов. Эта глава про другое: как из посчитанных цифр собрать аргументацию, которая выдержит разговор с финансовым директором или бюджетным комитетом. Раздел 2.8 отвечает на вопрос «сколько». Эта глава — на вопрос «почему вам должны поверить и одобрить бюджет».

Почему это холодный расчёт, а не эмоциональная покупка

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

Пять категорий эффекта для защиты перед бюджетным комитетом

В разделе 2.8 экономический эффект был разложен на три общие категории. Ниже — то же самое, но глубже: с конкретными кейсами и логикой расчёта для каждой категории, специфичной именно для разговора с финансовым блоком.

Ускорение бизнес-процессов: где обычно зарыто золото

Эта категория обычно даёт наибольший эффект, потому что считает не время сотрудников, а влияние скорости сделки на деньги компании. Задайте вопрос: как скорость подписания договора влияет на выручку, старт проекта или денежный поток? Если такая связь есть — считайте эффект через неё.

Экономия на ФОТ: почему в России считать сложнее

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

Экономия на накладных расходах

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

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

Самая методически сложная категория, но и одна из самых убедительных, если её правильно применить. Прямые потери при увольнении сотрудника из-за выгорания на рутинной работе оцениваются в 3–20 окладов. Эта цифра складывается из нескольких статей:

Методика расчёта стоимости неудачного найма подробно описана в книге Джеффа Смарта и Рэнди Стрита «Кто. Решите вашу проблему номер один». На защите эту категорию эффективнее применять не как основной довод, а как дополнительный аргумент — с формулировкой «при этом мы никого не увольняем, а снижаем отток». Если в компании есть HR-директор с KPI на удержание сотрудников, эта категория — хороший повод сделать его союзником проекта.

Потери от ошибок

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

Приём: считать эффект на горизонте нескольких лет, а не одного года

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

Как защитить цифры документально

Главный вопрос, который звучит на защите: откуда взялась та или иная цифра. Лучший ответ — не оценка на глаз, а зафиксированный результат пилотного проекта.

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

Типичные возражения финансового блока и как на них отвечать

К этому моменту у компании уже есть результаты обследования (глава 2) и экономическое обоснование (глава 3). Эта глава — про то, как выбрать конкретного вендора и технологию, не полагаясь на впечатление от демо и красивую презентацию.

Анализ рынка через Jobs to be Done

Когда сравниваете продукты на рынке, смотрите не на то, сколько в решении модулей и функций, а на то, способно ли оно выполнить конкретную задачу, ради которой вы его выбираете. Это логика методологии Jobs to be Done¹ (JTBD): продукт оценивают не по количеству возможностей, а по тому, справляется ли он именно с той «работой», ради которой его нанимают.

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

Риск избыточных требований к функциональности

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

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

Двухэтапный тендер: сначала квалификация, потом цена

Если позволяет закупочная процедура (для процедур по 223-ФЗ это, как правило, возможно; уточняйте применимость к вашему случаю), разделите тендер на два этапа, а не выбирайте вендора по цене напрямую.

Этап 1: квалификация. Отсеиваются участники, не соответствующие базовым ожиданиям:

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

Этап 2: цена. Здесь возможны два подхода:

Пилотный проект и его метрики

Демонстрация на вебинаре и реальная работа с продуктом — разные вещи. Пилот — способ проверить это на практике до подписания основного контракта.

Два формата доступа к продукту до контракта:

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

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

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

Референс-визиты

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

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

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

Проверка устойчивости вендора

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

¹ Jobs to be Done (JTBD, «работы, которые нужно выполнить») — методология, при которой продукт или решение оценивают не по набору функций, а по тому, какую конкретную задачу («работу») пользователь хочет с его помощью решить. Теорию популяризировал Клейтон Кристенсен в книге «Competing Against Luck» (2016); методологические основы также заложил Тони Ульвик (Strategyn). Почитать: Clayton M. Christensen, «Competing Against Luck».
Посмотреть: доклады и видеообъяснения на канале Christensen Institute.

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

Где ИИ даёт быстрый эффект в контрактном процессе

На что не стоит рассчитывать

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

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

Ограничения

Методика вывода метрик из болей AS IS подробно описана в разделе 2.7. Здесь — консолидированная сводная таблица: типовые значения, на которые можно ориентироваться при калибровке собственного расчёта. Это не универсальный норматив, а отправная точка — у вашей компании цифры AS IS могут отличаться, но диапазон целевых значений TO BE в практике внедрений остаётся устойчивым.

Скорость

Качество

Эффективность юридической функции

Заключительная глава — короткий ориентир на то, какую роль в апгрейде контрактного менеджмента играет сама технология: что переходит под управление системы, а что в любом случае остаётся зоной ответственности человека. Это не техническое задание, а рамка, с которой удобно сверяться при финальном выборе решения (глава 4) и при формулировании TO BE (раздел 2.6).

Что автоматизируем, а что остаётся за человеком

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

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

• конструктор документов с логикой ветвления и автозаполнением из справочников;
• настройку маршрутов согласования на основе матрицы рисков;
• интеграцию с учётными системами, ERP и справочниками контрагентов;
• контроль сроков и обязательств с уведомлениями;
• хранение всех версий, документов и истории сделки в единой карточке;
• при необходимости — применение искусственного интеллекта для проверки, извлечения данных и работы с корреспонденцией (глава 5).

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