Перенос юридической практики из Excel в CRM: порядок работ
Решение уйти из таблиц обычно принимается быстрее, чем сам переход. Дальше начинается работа, которую редко планируют: разобрать, что накопилось в файлах, решить, что переносить дословно, что пересобирать, а что не переносить вовсе. Ниже — последовательность этих шагов и типовые места, где перенос буксует. Материал информационный и описывает организацию работы, а не применение норм к конкретному делу.
Инвентаризация: что на самом деле ведётся в файлах
Первый шаг — не проектирование новой структуры, а опись существующей. Кроме основного реестра дел почти всегда обнаруживаются отдельный файл по расчётам с доверителями, календарь заседаний у помощника, личный список задач кого-то из юристов и папка со сканами, названная по своей логике. По каждому источнику фиксируется, кто его ведёт, с какой периодичностью обновляет и кто им пользуется, кроме автора. Именно на этом шаге выясняется, что один доверитель существует в трёх файлах в трёх написаниях, а колонки, которые считались обязательными, последний раз заполнялись год назад.
Заброшенное поле — кандидат скорее на удаление, чем на перенос, но сначала стоит понять, почему его перестали вести. Часть таких полей бросили не из-за ненужности, а потому что в одиночку их не удержать: дата вступления решения в силу требует, чтобы кто-то отслеживал движение по апелляции, и без такого человека колонка обречена. Эти поля имеет смысл вернуть в работу после переноса — но уже с назначенным ответственным, иначе они опустеют повторно, просто в другом интерфейсе.
Строка таблицы почти никогда не равна одной записи
Плоская строка склеивает несколько объектов, и обнаруживается это по множественным значениям в одной ячейке. Два ответчика через запятую, «первая инстанция, подана апелляция» в колонке статуса, перечень дат заседаний в примечании, сумма вида «300 000 основной долг + проценты» — каждый такой случай при переносе разворачивается в отдельные записи: стороны, инстанции, события, требования. Если этого не сделать, данные загрузятся, но отбор по ним работать не будет.
Проверить готовность строки к разбору помогает вопрос, который в связанной модели решается фильтром: «покажи дела, где доверитель — ответчик, а ближайшее заседание в пределах двух недель». Если ответ на него в таблице требует глазами просмотреть лист, потому что процессуальная роль записана в свободном примечании, а даты заседаний лежат в одной ячейке через запятую, — эти два поля и есть первоочередные кандидаты на нормализацию. Как связанные сущности устроены в рабочей системе, показывает раздел «CRM для юристов».
Формулы переносить бессмысленно, переносите параметры
Ячейка хранит результат, а не норму, по которой он получен, и устаревает молча. Шаблон госпошлины, собранный до 9 сентября 2024 года, продолжает считать по дореформенным значениям: для судов общей юрисдикции нижняя ступень составляла 400 ₽ при верхнем пределе 60 000 ₽. По действующей редакции ст. 333.19 НК РФ (Федеральный закон от 08.08.2024 № 259-ФЗ) иск ценой до 100 000 ₽ облагается фиксированными 4 000 ₽, а предел по имущественному иску — 900 000 ₽; в арбитражных судах по ст. 333.21 НК РФ нижняя ступень — 10 000 ₽, предел — 10 000 000 ₽. Разница измеряется разами и по внешнему виду итоговой ячейки не определяется.
Проценты по ст. 395 ГК РФ и индексация присуждённых сумм (ст. 208 ГПК РФ, ст. 183 АПК РФ) устаревают иначе: они опираются на внешние ряды — ключевую ставку по периодам её действия и помесячные индексы, — поэтому итог верен только на дату, когда его посчитали. Переносить нужно входные данные: сумму, дату начала и окончания просрочки, движения по долгу, поскольку частичные оплаты меняют остаток внутри периода и разбивают расчёт на части. При таком составе расчёт повторяется на новую дату одним действием, а не набирается заново перед каждым заседанием. Подробнее о том, как расчёт живёт в материалах дела, — в отдельном материале.
Что чинить до загрузки, а что после
До загрузки исправляется то, по чему устанавливаются связи и строится отбор. Это форматы дат — текстовые «12.03.24» вперемешку с настоящими датами не отсортируются; суммы, записанные как текст с «руб.» и неразрывными пробелами; номера дел, набранные с латинской «A» вместо кириллической; и дубли доверителей, возникшие из разного написания одного наименования. Пока эти четыре вещи не приведены в порядок, любая загрузка даёт правдоподобный, но неработающий результат.
Всё остальное — описания, комментарии, теги, оценки перспектив — дозаполняется по ходу работы и задерживать перенос не должно. Чистка данных легко превращается в самостоятельный проект без финала, поэтому критерий готовности стоит задать заранее и в проверяемом виде: связи между доверителем, делом и документом устанавливаются без ручной правки, а фильтр по дате и ответственному возвращает тот же список, который юрист составил бы вручную.
Очередь загрузки: справочники, активные дела, архив
Порядок задаётся зависимостями. Сначала загружаются справочники — доверители и контрагенты, суды, сотрудники с их ролями и правами; затем активные дела, которым нужен полный рабочий контекст: стороны, требования, инстанция, ближайшие даты, ответственный, документы; и только в конце архив. Начинать разумно с пилота на одном направлении или одном юристе на пару недель: ошибки в структуре обнаруживаются на десятке дел так же надёжно, как на пятистах, но исправляются несопоставимо дешевле.
Архив переносится по укороченной схеме. Закрытые производства нужны для поиска и для момента, когда прежний доверитель возвращается с новым вопросом, — для этого достаточно доверителя, номера дела, суда, предмета спора, исхода и ссылки на комплект документов. Восстанавливать в архивных карточках отработанные сроки и снятые задачи не нужно: эти данные уже не влияют ни на одно решение, а времени на них уходит больше, чем на все активные дела вместе.
Параллельный период и день, когда таблица перестаёт быть источником
Какое-то время данные ведутся в двух местах, и это нормально ровно до тех пор, пока обе системы не станут «наполовину настоящими». В этом состоянии расходятся именно те сведения, ради которых всё затевалось: срок записали в таблицу, задачу поставили в системе, а напоминание не сработало нигде, потому что каждый считал, что смотрит полную картину. Разделять надёжнее по типу данных, чем по времени: с назначенной даты сроки и задачи ведутся только в новой системе, а расчёты с доверителями ещё месяц можно закрывать в привычном файле.
У таблицы должен быть последний день, и объявить его недостаточно — файл лучше перевести в режим только для чтения и убрать из общей папки. Договорённость «теперь пишем в системе» проигрывает привычке, пока прежний файл открывается в один клик из закладок. Заодно эта дата даёт точку отсечения для сверки: всё, что появилось после неё, обязано быть в системе, и любое исключение — повод разобраться, какой сценарий работы не был учтён при переносе.
Чем проверяется, что перенос состоялся
Проверять стоит не полноту загрузки, а способность системы отвечать на рабочие вопросы. Берутся три-четыре контрольных числа на одну и ту же дату — количество активных дел, суммарная цена требований по портфелю, перечень заседаний на ближайшие две недели, список дел без ответственного — и сравниваются с тем, что даёт старая таблица. Расхождение почти никогда не означает потерю строк при загрузке: обычно оно вскрывает поле, которое в таблице заполнялось не по тому правилу, о котором все думали.
Вторая проверка — на людях. Юрист, не участвовавший в переносе, собирает в системе картину по своему делу: последний судебный акт, ближайшая контрольная дата, состояние расчётов с доверителем. Если хотя бы за одним элементом он возвращается в старый файл, работа не закончена, и этот элемент — её оставшаяся часть. Такая проверка занимает полчаса и заменяет длинный чек-лист миграции, который всё равно составлялся по памяти.