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

Кривая эффективности и повторяемость ошибок

С увеличением количества дел и сотрудников появляется кривая убывающей эффективности.

Причины довольно приземлённые:

  • повторяющиеся задачи притупляют внимание;

  • растёт количество мелких операционных действий;

  • увеличивается вариативность ситуаций;

  • ошибки начинают возникать не в сложных местах, а в рутинных.

Есть ещё одна особенность юридических процессов.
Ошибка часто не проявляется сразу. Она может «всплыть» через полгода или год — когда уже поздно реагировать. Логи позволяют восстановить цепочку событий. Но это реактивная модель. Превентивности в ней нет.

Кроме того, человек не видит картину в целом. Он не может учитывать десятки похожих по метрикам дел и принимать взвешенное решение на уровне распределения. Глаз «замыливается».

Почему «добавим людей» не решает проблему

Интуитивное решение — нанять ещё специалистов. Но при масштабе это не устраняет системную причину.

Юридические процессы сложны по структуре:

  • появляются новые операции;

  • добавляются новые узлы;

  • вводятся новые гипотезы;

  • меняются стратегии.

Бывали ситуации, когда гипотеза срабатывала — отдельный узел давал результат. Но его не вшивали в систему. Через время о нём забывали. Показатели начинали падать. Приходилось возвращаться, искать, анализировать.

Это не проблема компетенции. Это проблема отсутствия наблюдаемой системы. Человек может удерживать локальный участок процесса. Но не эволюцию всей архитектуры.

Где именно ломается масштаб

Типовые точки отказа выглядят так:

  1. Решение принято, но не зафиксировано как правило.

  2. Регламент ≠ фактический процесс.

  3. Системные ошибки компенсируются вручную.

  4. Экспертиза не превращается в данные.

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

Что такое data-подход в этом контексте

Важно: data-подход — это не BI и не красивые дашборды.

Это:

  • фиксация событий;

  • учёт переходов;

  • измерение времени через распределения, а не средние;

  • хранение версий решений;

  • формализация успешных узлов в правила.

И главное — возможность сравнивать не одно дело, а массив.

Архитектура data-подхода

1. Событийная модель

Каждое дело представлено не статусом, а последовательностью событий.

Одно дело содержит в среднем 150–300 событий.
В системе — более 30 000 дел.

Это миллионы записей.

Событие содержит:

  • тип;

  • версию;

  • timestamp;

  • ответственного (human / system / external);

  • связь с документом;

  • флаг ожидания (wait / hold / timeout).

Статус дела — производная.

Первичны события.

2. Почему не статусы

Статус:

  • затирает историю;

  • не показывает переходы;

  • не отражает повторяемость;

  • скрывает петли.

События неизменяемы.
Любое изменение — новое событие.

Это позволило:

  • восстанавливать полную временную шкалу;

  • видеть расхождения регламента и факта;

  • анализировать распределения времени.

3. Активность и ожидание

Мы разделили:

  • активные действия;

  • ожидание человека;

  • ожидание внешней системы.

События маркируются источником:

  • system

  • human

  • external

Есть явные типы:

  • wait

  • hold

  • reminder

  • timeout

Так были обнаружены «вечные ожидания» — события, которые никогда не закрываются.

До этого они просто растворялись в статусах.

4. Восстановление процесса

Сначала граф строился вручную. Затем — полуавтоматически через агрегацию переходов.

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

После перехода на квантили стали видны перекосы и хвосты распределения.

5. Масштаб и производительность

При миллионах событий начали проявляться ограничения:

  • падение скорости запросов;

  • рост времени агрегаций;

  • необходимость расчётов по временным окнам.

Анализ не батчился, но агрегация по периодам стала обязательной. Именно здесь стало понятно: без событийной модели масштаб перестаёт быть управляемым.

6. Превращение аналитики в правила

Ключевой момент — данные начали менять поведение системы.

Например:

  • увеличены допустимые сроки на отдельных этапах;

  • исключены неэффективные узлы;

  • изменён порядок действий в медиации;

  • автоматизированы сценарии с высокой предсказуемостью.

Часть медиации стала кандидатом на автоматизацию до 95%.
Это стало возможно только после анализа массивов.

Пример: оптимизация медиации

Без data-подхода стратегия строится на опыте:

«в таких случаях обычно соглашаются»
«этот тип нарушителя реагирует быстро»
«здесь лучше подождать»

После анализа массива стало возможно:

  • сегментировать по метрикам;

  • измерить эффективность сценариев;

  • увидеть, где время работает против нас;

  • убрать лишние шаги.

Эффективность выросла. Издержки снизились.

Что будет без data-подхода

Если убрать событийную модель:

  • судебные процессы становятся хаотичными;

  • эффективность медиации падает;

  • расходы растут быстрее доходов;

  • маржинальность снижается.

Это происходит постепенно. И потому особенно опасно.

Ограничение data-подхода

Данные:

  • не заменяют экспертизу;

  • не упрощают юридическую сложность;

  • не убирают вариативность.

Но они делают масштаб наблюдаемым. А без наблюдаемости масштаб всегда превращается в хаос.

Вывод

Маленький юридический сервис может жить без data-подхода.

Но при росте объёма отсутствие событийной модели приводит к:

  • снижению эффективности;

  • росту ошибок;

  • потере управляемости.

Масштабирование — это не увеличение штата.
Масштабирование — это превращение опыта в инфраструктуру.