Время прочтения: 5 мин.

Задача была не простая. В наличии имелись log-файлы обработки заявок клиентов и оформление кредитов на примере одного из международных банков. Всего более 1 млн. записей.

Первое, что мы сделали – определились, «что такое хорошо и что такое плохо» для процесса выдачи кредитов. Мы решили, что «хорошо», когда по заявке клиенту выдан кредит, и «плохо», когда кредит клиенту не выдан. Для успешной выдачи кредитов в условиях повышенной конкуренции необходим высокий уровень удовлетворенности клиентов. Поэтому при поиске решений по оптимизации процесса мы сосредоточились на анализе взаимодействия Банка и клиента.

Следующий этап был одним из самых важных – изучение активностей по процессу. То есть необходимо было понять сущность действий, зафиксированных в log-файле. Как правило в log-файлах фиксируется короткая или символьная информация о действиях и без дополнительной информации невозможно понять, что же на самом деле происходит в процессе. Например, активность «Concept», зафиксированная в log-файле означала, что клиент отправил заявку в банк и автоматически выполнена первая оценка заявки. Для изучения активностей по процессу нам помогло описание полей к таблицам базы данных. Как правило каждый разработчик базы данных составляет описание таблиц. Это правило очень полезно и помогает пользователям понимать данные.     

Для того, чтобы наши выводы были корректными, необходимо было предварительно провести анализ данных и исключить из log-файла те, которые могли необоснованно «смазать картину» при построении графов. К таким данным мы отнесли все «незавершенные» заявки, то есть такие, по которым процесс принятия решения еще не был завершен, а также тестовые заявки.

После того, как мы добились корректности наших данных, можно было строить граф процесса и исследовать последовательность обработки заявок и оформления кредитов. Для построения графа мы использовали Prom. Была выбрана модель DFM (Directly-follows model). Граф быстро строится и отлично улавливает XOR и Loop узлы. Но нужно иметь ввиду, что он не умеет работать с параллельными процессами и OR узлами (заявка разбивается на офферы, которые по ней были отправлены клиентам). В Prom плагин так и называется “Mine directly follows model using DFM”. При построении первого графа мы увидели «паутину» всех взаимосвязей и последовательностей этапов обработки заявки и оформления кредитов. На данном этапе граф был неинформативен, т.к. включал избыточное количество связей. Вместе с тем, нас заинтересовало наличие переходов заявки в состояние «завершение» после формирования оффера или комплекта документов. Ниже я опишу как мы отработали данные переходы.

Граф, построенный с учетом всех взаимосвязей и последовательностей.  

Путем построения графов с разным количеством «шума» (такие взаимосвязи, которые являются нетипичными для процесса и содержат малое количество переходов состояния заявки), мы определили оптимальный уровень «шума» — не более 50%.

Граф процесса при 50%-ом уровне «шума»

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

Подготовка оффера для клиента в основном осуществляется после отправки заявки в банк, также заявки могут создаваться самим банком (может быть при посещении клиента банком, точнее не можем сказать, такая информация в логах отсутствует). Далее осуществляется сбор документов и формирование оффера для клиента. После того, как оффер сформирован, его направляют клиенту с последующим звонком. Клиент выбирает оффер, по остальным офферам работа завершается (O_Cancelled).

По выбранным офферам проводится сбор и проверка документов (W_Validate_application), по окончании – банком выдается кредит (A_Pending) или принимается отрицательное решение (O_Denied).

После построения графа нами был сделан вывод, что переходы состояний заявок, заинтересовавшие нас на первом этапе, являются отклонениями. Мы отфильтровали кейсы с помощью плагина Filter Log by Attributes и оставили на графах только те, которые содержат переходы заявки в состояние «завершение» после формирования оффера или комплекта документов заявки.

По построенному графу видно, что по всем таким заявкам были сформированы офферы, которые не уходили на согласование клиентам. При этом 73 заявки были закрыты сразу после этапа создания оффера (A_Cancelled), а 14 заявок были закрыты после отрицательного решения банка по заявке (A_Denied), что так же является отклонением, так как данный этап предусмотрен после полной проверки документов и клиента, т.е. после этапа валидации.

По итогам анализа мы сделали следующие выводы:

Выявленные аномалии составляют ~0,5% от всех обработанных заявок. Не смотря на их небольшую долю, у банка имеется риск негативного резонанса и репутационные риски. В данной ситуации для устранения отклонений актуально внедрение автоматизированных методов контроля жизненного цикла заявки.

Исследование процесса с использованием Prom дает возможность провести объективный анализ маршрутов фактического исполнения бизнес-процессов. Вместе с тем мы пришли к выводу, что в Prom затруднен анализ отклонений, имеющих небольшую частоту повторений. В следующих своих исследованиях мы запланировали тестирование Process Mining с использованием:

  • PM4Py (https://pypi.org/project/pm4py/ — открытая библиотека Python, поддерживающая алгоритмы интеллектуального анализа данных процессов),
  • Celonis (https://www.celonis.com/ — облачная платформа компании Celonis с встроенными инструментами Process Mining).

С результатами своих исследований мы обязательно познакомим читателей сообщества NewTechAudit!