Process Mining: операционный контур урегулирования

00 · КЕЙС ЗА 30 СЕКУНД

Кейс за 30 секунд

Проблема

Процесс урегулирования выглядел как набор статусов: было непонятно, где именно теряется время, почему возникают возвраты, какие SLA нарушены и сколько это стоит бизнесу.

Что сделал

Разложил журнал событий в process mining модель, выделил нормальный путь и проблемные варианты, посчитал SLA, повторы, длительность узких мест и финансовый эффект для очереди действий.

Какое решение стало возможно

Какое управленческое решение должен поддержать экран?

Результат

Потенциал экономии 5,2 млн ₽ в месяц за счет SLA, повторов и контроля узких мест

Операции: process miningФинансы: 5,2 млн ₽/месКонтроль: SLA / повторыРешение: очередь узких мест

СтатусПотенциал

Периодоперационный месяц

Единицаруб./мес, SLA, backlog, повторы, длительность переходов

Методevent log → process map → bottleneck/rework/SLA → финансовая ranking board

До

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

После

Потенциал экономии 5,2 млн ₽ в месяц за счет SLA, повторов и контроля узких мест
артефакты: Process Map · Event Log · SLA Dashboard · Финансовая модель
Проверка обязательных полей event log: case id, activity, timestamp и owner.

подходящий режим работы

Architecture Review

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

короткий brief → разбор · когда нужно понять, какой контур решения строить первым

Вклад клиента: показать обезличенный артефакт, назвать решение и подтвердить владельца
Критерий выхода: зафиксированы риск, источник, проверка, владелец и первый шаг

01 · Что увидел руководитель

Потенциал экономии 5,2 млн ₽ в месяц за счет SLA, повторов и контроля узких мест

Какое решение стало возможным

Какое управленческое решение должен поддержать экран?

Какое управленческое решение должен поддержать экран?
Какие правила учета и контроля защищают расчет?
Какие исключения требуют владельца и SLA?
Что должно быть принято перед использованием?

05A · ТРЕБОВАНИЯ К КОНТУРУ

Почему архитектура выбрана так

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

ТребованиеОграничениеАрхитектурное следствие

Event logБез case_id, activity, timestamp и owner узкое место не доказать.event log + transition duration facts + SLA flags

Деньги в процессеСреднее время не показывает, где процесс теряет деньги.стоимость задержки на edge, rework loops и bottleneck ranking

Маршрут действияСигнал должен назначить владельца и безопасный маршрут.action queue, routing rules, acceptance criteria по SLA и очереди

Для тех, кто хочет вникнуть в реализациюконтекст, правила, архитектура, модель данных, методология и выводы

00B · ПРОЕКТНЫЙ ПАКЕТ

Такой проект можно адаптировать под ваш бизнес

Срок1-3 недели

Точный объем зависит от источников, качества справочников, количества владельцев и глубины приемки.

На выходе

карта текущего процесса и целевая модель
BRD/ТЗ, data model, расчетные правила и чеклист приемки
экран решения, отчет, Google Sheets-контур или разбор артефактов
список управленческих решений и владельцев действий

Как повторить

аудит текущей отчетности и ручных операций
проектирование справочников, правил учета и проверок
передача результата через приемку, регламент и runbook

01 · КОНТЕКСТ

Бизнес-контекст

Операционный контур с большим числом заявок, ручных проверок, возвратов документов и согласований. Все параметры в публичной версии обезличены и заменены demo-слоем.

02 · ПРОБЛЕМА

Проблема

03 · РОЛЬ

Что я сделал

Моя зона ответственности

Зона клиента

Дать доступ к источникам или обезличенным выгрузкам, подтвердить правила, назначить владельцев данных и принять критерии результата.

Ограничения

5,2 млн ₽/мес — потенциал эффекта, а не подтвержденная экономия

04 · БИЗНЕС-ПРАВИЛА

Бизнес-логика и правила

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

05B · АРХИТЕКТУРА

Архитектура данных

Architecture map · NDA-safe demo

Process Mining: операционный контур урегулирования (sources → rules → model → decision)

Раскрывай уровни как матрешку: L0 показывает контур, L1 открывает слой, L2/L3 дают подпроцессы, проверки и решение.

NDA-safe

L0Источники и загрузкаsources → intake → raw layer

L0Бизнес-модель и правилаfacts / views / marts

L0Управленческий слойэкран / владелец / решение

Все уровни свернуты

Открой L0-этап, затем L1-блок. Детали не занимают экран, пока они не нужны.

Слои подробнее

Источники

журнал событий системы урегулирования
SLA-правила
справочник владельцев
финансовые допущения

Загрузка

нормализация событий
сборка кейса
проверка timestamp
поиск вариантов

Хранилище

события процесса
факты переходов
SLA-нарушения
повторные циклы
модель эффекта

Витрина

карта процесса
варианты процесса
карта узких мест
SLA-контур
очередь действий

Почему так

Event log выбран вместо отчёта по среднему времени: денежная потеря возникает на конкретном переходе, в повторе и SLA-очереди.

Trade-off

Качество карты зависит от стабильных case_id, timestamp и владельца; пропуски событий искажают узкое место.

Когда мигрировать

Следующий уровень — потоковая маршрутизация, когда правило риска подтверждено и ручная очередь уже не успевает за объёмом.

06 · МОДЕЛЬ ДАННЫХ

Модель данных / витрины

fact_process_eventfactcase id, activity, timestamp, owner, status и reason code

fact_transition_durationfactпереходы между активностями, длительность, база и отклонение

vw_process_variantviewнормальный путь, узкое место, повторы и SLA-нарушения

mart_process_action_queuemartузкое место, владелец, действие, срок, эффект и статус закрытия

07 · МЕТОДОЛОГИЯ

Методология, процедуры, модель и эффект

Методология

Сначала нормализовал журнал событий: case id, activity, timestamp, owner, status, duration и reason code.
Построил варианты процесса: нормальный путь, путь с узким местом, путь с повторами и путь с SLA-нарушением.
Для каждого отклонения посчитал эффект в часах, рублях и клиентском риске, чтобы экран завершался очередью действий.

Что перенесено в систему

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

Модель и критерии

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

Измеримый эффект

Потенциальная экономия: 5,202,342 ₽ в месяц и 62,428,104 ₽ в год.
Эффект за период: 124,856,208 ₽; ожидаемый ROI программы 300-400%.
SLA: 4 471 нарушение порога 48 часов; финансовый эффект 22,355,000 ₽.
Узкое место: переход 'Урегулирование → Утверждение' добавляет +12,9 часов ожидания.
Потерянные документы: 5 048 кейсов, 6 609 поисков и 9 914 часов ручной потери.
Повторы: 11 663 кейса, 23,4% процесса уходит в повторные циклы.

10 · ВЫВОДЫ

Выводы и улучшения

Process mining полезен бизнесу только тогда, когда заканчивается решением: убрать узкое место, закрыть SLA, сократить повторы.
Операционный риск нужно переводить в деньги, иначе он остается абстрактной проблемой процесса.
Экран должен показывать вариант процесса, финансовый эффект и владельца действия в одном месте.

08 · ДОКАЗАТЕЛЬСТВА

Артефакты, валидация и эффект

Decision Trace ключевой цифры

01 · Источник

журнал событий системы урегулирования

02 · Правило

Каждый кейс проходит путь: регистрация → проверка документов → антифрод → урегулирование → утверждение → выплата.

03 · Расчёт

Оценка узкого места считает превышение длительности перехода над базой и ранжирует переходы по потерянным часам.

04 · Сверка

case id, activity, timestamp, владелец, SLA, rework loop и расчет узкого места

05 · Экран

Process Map

06 · Действие

Какое управленческое решение должен поддержать экран?

Цепочка доказательности

АртефактПроверкаБизнес-эффект

Журнал событийcase id, activity, timestamp, владелец, statusпроцесс становится измеримым по шагам, а не по ощущениям

Карта узких местдлительность перехода против базыожидание +12,9 часов получает владельца и срок устранения

Очередь SLA / повторов4 471 SLA-нарушение · 11 663 повторных кейсафинансовый эффект 5,2 млн ₽/мес переводится в план действий