До определённого момента юридический процесс кажется управляемым.
Есть стадии, статусы, отчёты, дедлайны. Пока дел немного, это работает.
Но когда их становится больше сотни, иллюзия управления начинает разваливаться.
Именно в этот момент я впервые понял, что с процессами что-то не так.
Когда статусы перестают что-то объяснять
Проблемы начали проявляться не сразу и не в одном месте.
Одни дела шли быстро, другие — зависали без видимых причин.
Срывались сроки — иногда по вине судов, иногда по вине сотрудников, иногда из-за внешних сервисов. Почта не отправила письмо. Документы потерялись. Ответчик вышел на связь, но «забыл» подписать.
При этом в системе всё выглядело нормально.
Статусы обновлялись. Отчёты сходились. Формально процесс шёл.
На практике же возникали странные петли: одно и то же действие приходилось выполнять снова и снова — отправить, отследить, напомнить, снова отправить, снова отследить. Эти loop-действия не считались ошибкой, но именно они съедали время и внимание.
В какой-то момент стало очевидно: мы управляем не процессом, а его описанием.
Масштаб ломает интуицию
Проблема резко усилилась на масштабе.
Результаты и путь единичного дела совершенно не похожи на результаты и путь массы дел.
Отдельное дело можно «прочувствовать»: понять, где оно застряло и почему.
Когда дел десятки тысяч, это перестаёт работать.
Команда регулярно давала уверенные оценки — особенно в медиации и судебном разбирательстве. Эти оценки почти всегда строились на ощущениях:
«обычно тут быстро», «в таких случаях всё решается», «этот этап проблемный».
Когда мы начали сравнивать эти мнения с фактическими данными и автоматизированным прогнозом, расхождения оказались системными.
Ощущения почти всегда ошибались.
Не потому, что команда плохая.
А потому, что человек плохо видит процессы, когда они нелинейны и разветвлены.
От статусов к событиям
В какой-то момент стало ясно: статусы не показывают процесс.
Статус — это точка.
Процесс — это путь.
Мы попробовали посмотреть на юридический процесс как на последовательность событий, а не как на смену состояний.
Не «дело находится в статусе X», а:
-
событие произошло;
-
затем было ожидание;
-
затем ручное вмешательство;
-
затем возврат;
-
затем пауза;
-
затем продолжение.
Каждое действие, каждое ожидание, каждое вмешательство стало отдельным событием с временной меткой и контекстом.
Источники событий и логирование
События собирались из нескольких источников:
-
из основной базы данных;
-
из очередей;
-
из внешних сервисов — почты, судов, API.
Логирование происходило синхронно в момент действия.
Это было принципиально: мы не хотели восстанавливать процесс задним числом по косвенным данным.
При этом довольно быстро выяснилось, что первоначального набора событий недостаточно.
Некоторые участки процесса «терялись», и их приходилось восстанавливать и аккуратно переносить на временную шкалу. Это привело к расширению событийной модели и пересборке части истории.
Модель событийных данных
Event log хранился рядом с делом, а не в отдельном аналитическом контуре.
Каждое событие включало:
-
case_id— идентификатор дела; -
event_type— тип события; -
timestamp— момент времени; -
actor— источник события (система, человек, внешняя среда); -
version— версия события; -
связь с документом или действием.
Для случаев, которые выходили за рамки типового процесса, дела помечались как «заплутавшиеся» — требующие нетипового вмешательства специалиста. Такие кейсы выводились в отдельную очередь (условно, h-case), чтобы не искажать общий поток.
Работа со временем и ожиданием
Один из ключевых моментов — корректная работа с ожиданием.
Мы жёстко различали:
-
активное действие;
-
ожидание внешней системы;
-
ожидание человека.
Каждое событие всегда имело указание ответственного:
система, человек или внешняя среда.
Ожидание не вычислялось постфактум — для этого существовали явные события hold, wait, timeout, reminder.
После их появления внезапно обнаружилось довольно много «вечных ожиданий» и событий, которые формально начались, но никогда не закрывались. До событийной модели эти проблемы были практически невидимы.
Восстановление реального процесса
Граф процесса сначала строился вручную, затем полуавтоматически.
Полностью автоматическая реконструкция — это постоянный процесс улучшений.
Важно, что мы не использовали:
-
frequency-based фильтрацию;
-
time-based оптимизацию;
-
отсечение редких путей.
Нас интересовала реальная картина, а не «красивый» процесс.
Особенно показателен был момент, когда восстановленный граф начал резко расходиться с регламентным процессом. Некоторые формально выстроенные этапы просто не работали так, как предполагалось. Это стало наглядно видно после введения квантилей по времени и переходам.
Масштаб и производительность
В среднем одно дело генерировало 150–300 событий.
Всего в системе — десятки тысяч дел.
Историю мы не резали, но данные приходилось агрегировать по периодам.
С ростом объёма эффективность начала падать — и именно в этот момент process mining перестал быть «интересным экспериментом» и стал необходимостью.
Использование результатов
Результаты анализа использовались напрямую:
-
в дашбордах;
-
в правилах;
-
в автоматических решениях.
Всё чаще возникали ситуации, когда аналитика говорила «не делать», а бизнес настаивал на обратном. Со временем именно данные начали выигрывать эти споры.
Благодаря process mining были:
-
намеренно увеличены сроки некоторых событий;
-
полностью перестроены отдельные процессы;
-
снижены операционные расходы.
Ограничения подхода
Важно подчеркнуть: process mining сам по себе ничего не «чинит».
Он:
-
не ускоряет суды;
-
не заставляет внешние сервисы работать стабильнее;
-
не заменяет принятие решений.
Он лишь делает процесс наблюдаемым.
Но именно это и оказалось критичным: стало понятно, где решение вообще имеет смысл, а где проблема лежит за пределами системы и не решается автоматизацией.
Вывод
Статусы, отчёты и KPI создают ощущение управляемости. Но без понимания реального потока событий это ощущение быстро превращается в иллюзию.
Process mining в нашем случае оказался не инструментом оптимизации, а способом увидеть реальность. А без этого любые попытки масштабирования лишь увеличивают объём хаоса.
Автор: kirill_knaub
