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

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

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

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

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

• Проект превратится в автоматизацию ради автоматизации, так как нельзя отследить эффективность переезда без чётких метрик.

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

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

• Могут возникнуть проблемы с переносом данных. Миграция может превратиться в отдельный проект, так как «скопировать-вставить» чаще всего не получается.

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

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

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

• Зафиксируйте точку A. Детально изучите, как устроены текущие процессы, и подробно их опишите.

• Зафиксируйте точку B. Определите и зафиксируйте требования к будущим процессам и системе.

• Используйте переезд как возможность пересмотреть процессы. Стратегия «копировать → вставить» не улучшит автоматизацию. При переезде нужно выбраться из операционки и посмотреть на работу «сверху».

• Сфокусируйтесь на главных функциях. Реализуйте только тот функционал, который решает вашу главную задачу.

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

• Реалистично оценивайте возможности новой платформы. Используйте все инструменты анализа решений: от референс-визитов до пилотных проектов.

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

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

• Конфликт интересов. Когда цели противоречат друг другу, бизнес-заказчик, IТ-подразделение и подрядчик действуют несогласованно.

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

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

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

• Сформируйте единую проектную команду. Юристы, IT и вендор должны работать как одно целое, а не как три разных отдела.

• Поставьте общую цель. Все участники должны одинаково понимать, куда движется проект. Иначе каждый будет грести в свою сторону.

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

• Создайте реалистичный план. Он должен быть гибким и управляемым. Все изменения — с оценкой влияния на сроки и бюджет.

• Пробелы в знаниях пользователей
• Неудобство использования платформы
• Усталость команды

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

• Управляйте изменениями по методологии. Например, можно попробовать ADKAR или что-то другое, но главное, чтобы изменения были системными.

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

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

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

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