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

Как выбрать, какую задачу автоматизировать первой?

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

  • повторяемость - если юристы выполняют одинаковые действия регулярно: например, ответы на типовые претензии, рассмотрение договоров, выдача доверенностей и т.д.;
  • большой объем - если операций много, даже если каждая занимает мало времени;
  • правила - если есть алгоритм и решение можно описать в правилах вроде «если А, то Б, если В, то Г»;
  • понятный владелец процесса - человек, который отвечает за процесс;
  • измеримость результата - желательно, чтобы можно было посчитать эффект, например: до автоматизации на операцию требовалось 3 часа, теперь нужно 15 минут;
  • ограниченный контур - первый проект лучше брать такой, где можно сделать MVP (минимально жизнеспособный продукт) без многочисленных интеграций и участия половины компании.

Для выбора задачи под автоматизацию подходят методы приоритизации. Например, можно использовать Weighted Scoring. Сначала нужно выбрать свои критерии и задать каждому вес, то есть насколько он важен (например, так, чтобы в сумме было 100%). Затем каждый процесс оценивается по каждому критерию от 0 до 10. Чтобы оценки были сопоставимыми, лучше заранее определить, что означает каждый балл. Оценка умножается на вес, результаты складываются, и процессы сравниваются по итоговой сумме.

wUzytyDuVGkdYUVj_4Gz5YKkqS1YfDeundKUPk9G_qIlzW8Zq4BCjYrsgi8qYbWh2UbaS8zKj4Wx0TEQ5FpB9W6J

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

Еще подходящие методики приоритизации:

Value/Effort (2×2). Нужно заполнить квадранты: быстрые победы (это то, что надо брать в первую очередь), крупные проекты (обещают высокую отдачу, но требуют значительных ресурсов), «заполнители» (задачи с низкой ценностью, но требующие небольших усилий) и то, что не делаем.

MoSCoW. Нужно заполнить: must have (обязательно) - задачи, без которых проект не достигнет цели или провалится, should have (стоит сделать) - важные задачи, которые улучшают продукт, но их отсутствие не блокирует работу, сould have (можно сделать, если останутся ресурсы), won’t have (в этом цикле делать не будем).

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

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

Как собрать информацию о процессе?

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

Следует провести интервью с сотрудниками, понаблюдать за их рабочим днем («фото рабочего дня»), проанализировать данные из ИТ-систем и переписки, внутренние документы, замерить длительность операций и ожидания.

Интервью нужно провести:

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

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

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

Как описать процесс?

После сбора информации нужно описать текущее состояние процесса, его называют as-is («как есть»), а также целевое - to-be («как будет»). Без замера as-is будет сложно доказать эффект. Описывать процессы можно, используя устоявшиеся инструменты. Ниже перечислю несколько из них, которые используются на практике.

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

SIPOC. Этот инструмент подходит для первоначального определения границ процесса. Нужно заполнить следующие столбцы:

  • Suppliers (поставщики): кто/что подает входы, то есть с кого все начинается
  • Inputs (входные данные): что необходимо для выполнения
  • Process (процесс): ключевые этапы (не более 5-7)
  • Outputs (выходные данные): результаты, которые получаем
  • Customers (получатели): кому передаются результаты

Вот так могут выглядеть заполненные столбцы SIPOC

fC7g61vh7c2Xu15Tpz_08JGsHVzmf2TTu8sAVOYMxSnN7PAQEwPyA9ZmGpK0oAjETSJevqhZ9B3D1RFdU1e2CY3h

VSM (карта потока создания ценности). Этот инструмент показывает весь путь услуги, потери и время операций. Он позволяет выявить «узкие места» и неэффективность: например, где тормозит процесс согласования договора и сколько тратится времени.

0ilYxOpn-_Vf-peFmAuxpsQYAKXj74pHagDWnhuEtsUjZtdwEBNOHA2-Go0RRr406xjoSCn7AMx1JR7K_bjFF1yH

Нотации. Существуют разные нотации (схемы), но для юридических процессов хорошо подходит BPMN (еще используют нотацию EPC). BPMN – это детальная нотация для сложных процессов, которые планируется автоматизировать (выглядит, как дорожки в бассейне, где каждая дорожка – это отдельная роль). Она используется для графического моделирования логики процесса, ролевой модели, развилок и точек принятия решений.

lY6H4MjzfdiiwAwQnqtveK9IGB7OtP6XLTGGTFv9Ku02SelsD3qJvXHbFSHfbEoCORr2IMzUSQEwZ36ttAuJbZpO

Схемы можно рисовать в универсальном редакторе draw.io. Также есть специальные сервисы с ИИ, в которых можно не только нарисовать BPMN, но и найти ошибки в схеме: например, stormbpmn.com. Либо можно воспользоваться нейросетями, например, Claude, ChatGPT. После описания и анализа процесса стоит приступать к поиску узких мест. Например, можно увидеть, что:

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

После этого описываем процесс to be.

Что еще нужно сделать

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

Способы автоматизации с минимальными вложениями

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

Автоматизация в Word или Excel. В типовых документах можно настроить поля для заполнения. Тогда Word может выглядеть как заполняемый конструктор.

GYmR_izk1ROPYzZJ5qZJ6H2d1AXPOytOM6JnJMGjGqqNuuE5YApxud8I2zwM6g7GAwHjRk73eCmjPssYnhU5f9oQ

Макросы и скрипты в офисных пакетах. Например, их можно использовать, когда нужно:

  • автоматически сформировать все документы к собранию совета директоров (бюллетени, протокол), заполнив только одну таблицу-анкету с основными данными;
  • разложить пакет документов по папкам с переименованием и т.д.

No-code, интеграции и сервисы со скриптами. Нужно учитывать варианты использования небольших сервисов и интеграций. Например, можно сделать с помощью Яндекс Формы или бота в Телеграм прием заявок в юрдепартамент со структурированными полями вместо писем, которые приходят юристам на почту. Возможно создание небольших сервисов (с ИИ или без) для генерации типовых претензий или исков, мониторинга судебных дел и т.д. Такие сервисы можно навайбкодить с помощью ИИ (например, в Claude Code, Codex, Cursor). Еще используют no-code платформы (n8n, Albato, Make и т.д.).

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

  • Проекты. Это рабочее пространство с постоянными инструкциями и файлами: типовыми формами, плейбуком, позициями компании, внутренними политиками. Любой новый чат внутри проекта уже знает этот контекст, и не нужно каждый раз заново объяснять, кто вы и как принято работать. Например, в проекте «Претензии» могут быть шаблоны и позиции компании по типовым спорам. На выходе получится черновик ответа на претензию.
  • Скиллы (навыки). Это инструкция, как выполнить конкретную задачу: какие шаги пройти, что проверить, в каком формате выдать результат. В скилл можно положить шаблон, чек-лист и даже небольшой скрипт. Например, скилл «Проверка договора поставки по чек-листу».
  • Коннекторы. Они подключают ассистента к системам, с которыми работает юрист: к почте, календарю, облачному диску, трекеру задач, СЭД. Также можно подключить коннектор (MCP) к базе знаний (например, как в CasusLegal – можно подключить коннектор к базе судебных актов или к Глосса – комментариям гражданского законодательства под редакцией Артема Карапетова).

Специализированные legal AI. Можно использовать платные и бесплатные сервисы для поиска судебной практики и законодательства: Нейроюрист, Искра от Гаранта, Law.GPT, Explain.law и т.д. Вместо глобальных разработок для рассмотрения договоров можно использовать, например, Doczilla, Noroots.

Примеры автоматизации для новичков и зрелых компаний z3lS7mYLH79JSR0KNzHu96yNtAqZ91Ku96iiW6ftMH75D3mOhtN_1hGNKGCPQw7QfWj81ahILzkljIDwV0Jl6KTg

В Лаборатории LegalTech&Ops мы занимаемся оптимизацией и автоматизацией юридических процессов. Напишите нам - проведем диагностику и подберем или разработаем подходящее вам решение.