In Tech We Trust, но есть нюанс. Почему технологии часто не решают проблемы юристов

На лекциях по цифровизации юрфункции мы часто слышим один и тот же вопрос: «Какой конструктор документов лучше?».

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

Разберем четыре основных фактора, о которые чаще всего спотыкаются проекты по цифровизации.

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

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

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

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

📄 Данные
Руководству презентуют наглядный дашборд с аналитикой. Но если в исходных реестрах кочуют ошибки, неверные статусы и дубли, система просто визуализирует плохие данные. В какой-то момент красивые графики начинают расходиться с реальностью. Из-за ручного ввода одни юристы заносят контрагента как «ООО Ромашка», другие — как «РомаШка ООО». В итоге дашборд дробит статистику, искажает суммы рисков по ключевым партнерам, и общая картина просто разваливается на части.

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

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

Вместо экономии времени получается дополнительная рутина по обслуживанию софта.

Получается парадокс: инвестиции в технологии растут, а скорость и управляемость функции остаются на прежнем уровне.

С какими из этих барьеров — саботаж команды, кривые процессы, «грязные» данные или разрозненные ИТ-системы — вы сталкиваетесь чаще всего? И как вы их преодолеваете?

⭐️Пятница — хорошее время поговорить о цифровизации, в которой все заняты, но никто никуда не едет.

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

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

https://telegra.ph/Cifrovizaciya-kak-hobbihorsing-pochemu-mozhno-mnogo-skakat-i-nikuda-ne-priehat-09-04

❓Как обстучать идею цифровизации о реальность

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

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

Этот механизм хорошо разобран в книге «Спроси маму» Роба Фицпатрика, и подход из неё применим в проектах

Главная мысль: мнения почти бесполезны. На вопрос «вам будет удобно?» мы получаем вежливость, догадки и пожелания. Надёжны только факты о прошлом: что человек уже сделал сам, чем обходился, на что тратил время. Мнение бесплатно, а поведение дорого.

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

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

Рассмотрим два примера.

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

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

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

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

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

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

Только не переносите костыль в систему «как есть» он говорит о боли, но не о решении.


В следующем посте расскажем подробнее про процесс поиска таких костылей.

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

https://telegra.ph/Inventarizaciya-kostylej-kak-eyo-provesti-09-17