Быстро проверить договор — недостаточно

Недавно разбирали путь обычного договора внутри компании.

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

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

Ну проверили договор за 20 минут — и что? Если потом он два дня лежит в почте, ждёт ответа инициатора, а юрист вручную пересылает версии и сообщает статусы. Скорость проверки важна только через влияние на транзакции и выручку.

Поэтому мы сделали в noroots первую итерацию таск-менеджера для юристов.

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

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

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

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

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

То есть совместная работа — это сокращение пути от договора до денег.

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

Таск-менеджер для юр отдела

В прошлом посте я писал, что таск-менеджер noroots сокращает путь договора между инициатором и юристом.

Юрист получает договор. А что дальше?

Что это за сделка? Зачем она бизнесу? О чем договорились с контрагентом? Какой результат нужен инициатору?

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

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

Поэтому при загрузке договора в нашем таск-менеджере есть поле Цель сделки.

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

Но это не всё!
Классно, что инициатор еще до передачи задачи юристу может сам увидеть, что договор не закрепляет нужный результат. Вернуть его контрагенту, внести изменения и только потом отправить на юридическую проверку.

То есть часть договоров, которые вообще не должны были попасть к юристу, до него просто не дойдет.

Наш таск-менеджер не только двигает договор между участниками, он помогает не тратить время юриста на договоры, которые еще рано проверять.

А вы считаете важным донести до юриста цель сделки до начала проверки?
Лично я считаю, что часть договоров можно вообще до юристов не доносить, так как они не отвечают цели

Почему крутые ИИ-модели НЕ убьют традиционный софт? Урок истории от Джорджа Пульмана 🚂

Недавно по совету друга Хольгера Цшайге прочитал пост о Леопольде Ашенбреннере (экс-OpenAI), который "слил" миллиарды долларов своего фонда. Он сделал простую ставку: шортил (ставил на падение) софтверных гигантов вроде Adobe, Salesforce.

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

Это классическое инженерное заблуждение.

Чтобы понять, почему подписки на SaaS не умрут, а станут только дороже, вернемся в США 1870-х годов.

Главный чит-код «железнодорожной лихорадки»

В XIX веке инвесторы безумно строили железные дороги в США. Они вели ценовые войны и массово банкротились. Железнодорожные пути быстро обесценились и стали дешевым сырьем (commodity).

Но один человек заработал на этом миллиарды, не построив ни метра путей. Его звали Джордж Пульман.

Он создал компанию Pullman и сдавал в аренду роскошные спальные вагоны.
* Пассажирам было плевать на мощность паровоза и марку рельс. Им нужен был комфорт, сервис и безопасность.
* Ж/д компании не могли отказаться от вагонов Пульмана — клиенты требовали именно их.
* Пока строители дорог разорялись, Пульман десятилетиями забирал себе сливки и платил огромные дивиденды.

Современные SaaS - это «вагоны Пульмана» для ИИ

Сегодня OpenAI, Google и Nvidia строят «рельсы» (модели и чипы). Они сжигают сотни миллиардов в дикой конкуренции и тестировании инженерных гипотез. Вероятнее всего скоро стоимость генерации текста и кода упадет до нуля.

А традиционные SaaS-гиганты (Salesforce, Microsoft, Veeva) - это Пульманы наших дней. И вот почему они могут получить бенефиты:

1. Модель - это просто рельсы. Софт - это готовый процесс
Ни один банк или фармгигант не покупает софт ради «красивого кода». Его покупают ради готовых процессов и безопасности. Например, в софте Veeva хранится история испытаний лекарств для проверок Минздрава США. Любая ошибка - миллиардный штраф. Вы не замените готовую систему «голым» ИИ.

2. Замена софта - это корпоративное самоубийство
Попытка вырезать живьем CRM или ERP-систему из бизнеса и заменить её самописным ИИ - это гарантированный хаос. Ни один директор не пойдет на такой риск ради экономии 1% бюджета.

3. SaaS не борется с ИИ. Он продает его как доп. услугу

SaaS-компаниям не нужно создавать свои ИИ-модели. Они берут готовые «рельсы» от OpenAI и встраивают их в свои интерфейсы:
* Microsoft продает Copilot внутри Office 365 за +$30 в месяц.
* Adobe продает ИИ-генерацию картинок внутри Photoshop.
* Salesforce запускает ИИ-агентов поверх своих баз данных.

Итог: В любой технологической революции инфраструктурные строители сжигают капиталы. А сливки собирают те, кто сидит сверху.

ИИ-модели быстро станут дешевым сырьем. А прибыль заберут SaaS-гиганты, которые владеют интерфейсом, клиентом и его данными.

А вы как думаете?

Что такое безопасная сделка?

Безопасная сделка — это не сделка без рисков. Это сделка, в которой понятно, что может пойти не так, как от этого защититься.

Безопасная сделка изначально допускает факт неполучения денег, неоказания услуги и нарушения обязательств у сторон.

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

А когда дело дойдет до претензии или суда, окажется, что доказательств нет.

Поэтому мы хотим, чтобы noroots в будущем отвечал не только на вопрос «Как сделать эту сделку безопасной?»

Как это может работать
1. вы указываете, какой результат хотите получить и чего не должно произойти;
2. noroots отдельно проверяет договор и контрагента (в контексте сделки);
3. определяет, можно ли на практике получить нужный результат;
4. составляет план защиты: какие пункты изменить, какие документы запросить и что ещё сделать;
5. заранее предполагает возможные нарушения и говорит, какие доказательства надо собрать;
6. создает чек-лист документов, которые вы прикрепляете по ходу исполнения сделки.

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

Безопасная сделка — это:
1. Правильно подготовленные документы для защиты результатов сделки
2. Сценарии исходов сделки
3. Контроль исполнения
4. Изначальная подготовка к судебно-претензионнй работе на этапе закладки сделки.
5. Наличие ресурса для достижения результатов, включая судебную работу.

Мы пока размышляем над этой концепцией и хотим понять: вам был бы полезен такой процесс?

Что в нем самое ценное? И чего не хватает?

Ну и также скажите, почему я это видео использую для поста?

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

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

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

Маленький релиз перед большим обновлением ☺️

Теперь noroots видит не только договор, но и переговоры вокруг него

Можно загрузить договор с правками в режиме рецензирования и комментариями контрагента — noroots разберёт их вместе с текстом:

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

Для юриста договор — это не просто текст. Часто в одном Word-файле уже лежит вся история переговоров: исходные условия, предложения контрагента, комментарии сторон и новые редакции.

И мы хотим, чтобы noroots умел работать со всем этим контекстом так же, как работает юрист.

Раньше мы учили noroots читать договор. Теперь учим его читать переговоры вокруг договора.

По-моему, это очень круто!