Doczilla позволит
Полностью исключить простые ошибки;
Ускорить подготовку документов в 10 раз;
Избавиться от рутины и перепроверок;
Забыть про неактуальные шаблоны;

Как юрдепу переехать на новою платформу автоматизации: 3 вредных совета от тех, кто выжил

23.06.2025

Как юрдепу переехать на новою платформу автоматизации: 3 вредных совета от тех, кто выжил

23.06.2025

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


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

* Вебинар Doczilla. Часть Ивана начинается с 44:00

Главное

  • Переезд на новую платформу без подготовки — это копирование старых проблем в новое место. Решение изменится, но результаты останутся теми же.
  • Чтобы переезд прошёл без проблем, у всех отделов должна быть единая цель. В противном случае юристы, IT и вендор работают разрозненно. У каждого появляются свои задачи, возникает конфликт интересов, и в итоге проект разваливается.
  • Если не подготовить конечных пользователей к переезду со старой системы, они могут не принять новую платформу. Формально запуск состоится, но пользы от него не будет.

Вредный совет № 1. Не готовьтесь к переезду

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

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

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


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

  • Поставьте чёткую цель. Для этого нужно ответить на несколько вопросов: «Зачем проект?», «Какую проблему он решает?», «Какой измеримый результат мы ожидаем?»
  • Зафиксируйте точку A. Детально изучите, как устроены текущие процессы, и подробно их опишите.
  • Зафиксируйте точку B. Определите и зафиксируйте требования к будущим процессам и системе.
  • Используйте переезд как возможность пересмотреть процессы. Стратегия «копировать → вставить» не улучшит автоматизацию. При переезде нужно выбраться из операционки и посмотреть на работу «сверху».
  • Сфокусируйтесь на главных функциях. Реализуйте только тот функционал, который решает вашу главную задачу.
  • Разработайте детальный план миграции на самом старте проекта. Для этого лучше привлечь профильных IT-специалистов или стороннюю IT-команду.
  • Реалистично оценивайте возможности новой платформы. Используйте все инструменты анализа решений: от референс-визитов до пилотных проектов.

При переезде есть соблазн пропустить этап подготовки. Но в 100% случаев вам придётся совершить все вышеперечисленные шаги. Разница в том, что если начать разбираться в процессах параллельно с реализацией проекта, то переезд получится долгим, дорогим и неэффективным.

Формула, которая упростит переезд с одного решения на другое

* Формула, которая упростит переезд с одного решения на другое

Вредный совет № 2. Пусть каждый сотрудник отвечает только за свой участок работы

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


Чем грозит следование совету. Сотрудники станут как лебедь, рак и щука. У всех появятся разные цели: юристы захотят, чтобы новая система работала лучше прежней, IT — чтобы проект уложился в сроки, а подрядчик не будет упускать возможность нарастить бюджет за счёт доработок. Такая ситуация приведёт к негативным последствиям:
  • Конфликт интересов. Когда цели противоречат друг другу, бизнес-заказчик, IТ-подразделение и подрядчик действуют несогласованно.
  • Размытая ответственность. Если пустить всю коммуникацию на самотёк, то сотрудники начнут перекладывать решение проблем друг на друга.
  • Не будет выделенного руководителя проекта, который принимает ключевые решения. Сроки проекта станут резиновыми, а бюджет будет постоянно расти.

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

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

* Сравнение работы команд: слева — у каждого отдела своя задача. Справа — все отделы движутся к одной цели

Вредный совет № 3. Не обучайте пользователей, они разберутся сами

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

Чем грозит следование совету. Пользователи не примут новое решение и будут сопротивляться его внедрению. Причем сопротивление может быть от «мы ничего не хотим» до прямого саботажа и критики руководства. Это приведёт и к другим проблемам:
  • Пробелы в знаниях пользователей
  • Неудобство использования платформы
  • Усталость команды
В результате получится, что систему формально внедрили, но фактически она не приносит никакой пользы. Реальные цели переезда и автоматизации не будут достигнуты.

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

Чтобы автоматизация приносила реальную пользу, сфокусируйтесь на человеке:
  • Будьте открыты любой обратной связи. Настраивайте максимально широкие каналы общения с пользователями. Отрабатывайте возражения сразу, пока они не превратились в саботаж.
  • Управляйте изменениями по методологии. Например, можно попробовать ADKAR или что-то другое, но главное, чтобы изменения были системными.
  • Учитывайте мотивацию и нагрузку. Участники проекта и пользователи быстро устают, особенно когда не видят мгновенного результата. Если не следить за этим, то провалиться может даже самый продуманный переезд.
  • Создайте максимум поддержки. Обучение — это не вебинар ради галочки. Это и демонстрации ключевых функций, и нормальная техподдержка, и общение с командой. Чем понятнее продукт — тем выше шанс, что его примут.
  • Вовлекайте пользователей заранее. Не надо ждать запуска. Новые функции нужно показывать сразу: «Вот, мы сделали это — поделитесь мнением». И обязательно реагировать на него: «Ваши предложения войдут в следующий релиз».
ADKAR — популярная методология управления изменениями. Она помогает перестроить не только работу в системе, но и поведение сотрудников.
Схема марафона внедрения

* Успешное внедрение ИТ-решений — это марафон, а не спринт. Боритесь с когнитивными искажениями и громкими обещаниями подрядчиков. Проверяйте всё сами, не спеша

Не ждите, что IT-специалисты или вендоры смогут прочитать ваши мысли. Станьте полноценным партнёром и лидером изменений со стороны бизнеса — это залог того, что результат будет соответствовать ожиданиям.

Применение Doczilla

  • Ускорить подготовку документов в 10 раз
  • Полностью исключить простые ошибки
  • Забыть про неактуальные шаблоны
  • Избавиться от рутины и перепроверок

Читайте также