Как мы автоматизировали мониторинг статусов ипотечных заявок для клиента

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

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

Какая задача стояла

Исходная ситуация. Ипотечные заявки оформляются в отделениях банка или дистанционно через бэк-офис. Есть дашборд в Power BI, который показывает данные по заявкам, оформленным дистанционно. Информация из отделений поступает каждую неделю через CRM-систему. Чтобы получить отчетность, заинтересованным лицам нужно выполнить много операций вручную. Это объективно неудобно и затратно по времени. 

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

Какое решение выбрали

Команда аналитиков SimbirSoft предложила реализовать этот процесс с помощью Apache Airflow. Это распространенное приложение для управления множеством операций с файлами, иначе (на инженерном) — оркестратор для администрирования неструктурированных данных. Кроме простоты и многофункциональности, решение имеет подробную документацию, подходит для работы с Python-скриптами и быстро разворачивается с Docker. Кроме того, для него есть ряд расширений, которые позволяют работать, например, со скриптами на R и с JSON-исходниками.

Наличие огромного коммьюнити и большое количество готовых примеров позволяет решить практически любую задачу не своими силами. Кроме того, продукт совместим с другими продуктами Apache, позволяет разворачивать его на основном или на виртуальном сервере. 

При необходимости он работает с исходниками из таблиц Microsoft, имеет высокую производительность. Но у него нет встроенной системы построения дашбордов, хотя для этого есть другие системы дата-анализа, совместимые с Python. С учетом богатого Stack Overflow все недостатки уходят на второй план. Тем не менее, продвинутые знатоки машинного обучения и других теоретических основ дата-анализа могут быть недовольны отсутствием тонких настроек. Для таких случаев есть другие инструменты, которые могут использоваться совместно с AirFlow. В нашем кейсе это не помешало.

Что делали 

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

Сначала провели анализ требований для построения дашбордов. Требования были крайне схожи с теми, что применялись к дистанционно оформленным заявкам.

Получили доступы к серверу (username, password, host, port, name) для создания строки подключения и движка в DAG. Архитектура системы базируется на концепции направленного ациклического графа (DAG). В этом графе все вершины (задачи) связаны между собой в определенном порядке и нет циклов. Это позволяет отслеживать зависимости между задачами и запускать пайплайны в правильном порядке. В качестве базы данных мы использовали PostgreSQL.

Написали скрипт на Python, который выполнял следующие задачи:

1. Получение данных с сервера: созданный скрипт забирал данные с сервера за предыдущую неделю и сохранял их в соответствующую папку.
2. Проверка содержимого файла с отображением его в логах для гарантированного сохранения корректной информации и раннего предупреждения о сбоях.
3. Создание и проверка таблицы в базе данных: еще несколько задач внутри  создавали таблицу в базе данных, если она еще не была создана. Далее проверяли ее состояние и выдавали подробную информацию о ней для возможной диагностики.
4. Загрузка данных в базу: скрипт принимал файл из первой задачи по указанному пути, обрабатывал и загружал данные в базу данных, переименовывая поля и заполняя пропуски.

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

С какими трудностями столкнулись

Не все прошло так гладко, как могло показаться. В процессе работы мы столкнулись с несколькими трудностями. Во-первых, получение необходимых доступов заняло больше времени, чем мы ожидали. Эта задержка была вызвана особенностями финтех-сферы. Мы рекомендуем закладывать больше времени на этот этап, чтобы избежать задержек в реализации проекта.

Во-вторых, требования к итоговым отчетам несколько раз изменялись. Это приводило к необходимости внесения корректировок в уже настроенные автоматизированные процессы. Поэтому всем, кто решит пойти тем же путем, рекомендуем заранее закладывать достаточную гибкость в настраиваемые процессы, чтобы оставить себе возможность для их изменения в будущем и не затягивать сроки реализации.

Кроме того, настройка DAG требовала тщательного планирования времени запуска. Мы посчитали, что запуск DAG за 3-4 часа до начала рабочего дня будет оптимальным, чтобы данные успевали обновляться и были готовы к использованию утром. Однако из-за большого объема данных процесс загрузки мог затянуться. После нескольких итераций мы нашли другое оптимальное время для запуска и смогли обеспечить своевременное обновление отчетов.

Какие результаты получили

Инструменты дата-анализа позволили увеличить производительность по предварительной обработке данных практически в 9 раз, единовременно затратив 16 часов работы дата-аналитика.

Ранее данные из отделений загружались в течение понедельника, и только спустя двое-трое суток непрерывной обработки руководство получало информацию о статусах заявок за предыдущую неделю. Теперь вся предварительная работа с данными занимает не более 8-12 часов и происходит в ночное, нерабочее время. Утром следующего рабочего дня после старта их обработки данные уже можно анализировать. Это позволило снизить объем рутины в работе аналитиков и задержку при принятии решений о выдаче кредитов.
 

Данные автоматически поступают в хранилище и используются для дальнейшего анализа. Информация из CRM-систем всех отделений обрабатывается и сохраняется в PostgreSQL, формируя витрину данных. Витрина подключена к Power BI, в котором система строит дашборды и по мере поступления новых данных автоматически их обновляет.

В результате мы запустили и отладили работу DAG в интерфейсе, настроили подключение к базе данных в Power BI, ввели нужные параметры, выбрали таблицу и все — на этом работа по предварительной обработке данных завершена. Бизнес-аналитик и руководство могут заниматься своей работой, анализировать конкретные цифры о платежеспособности клиентов и рисках. Так мы помогли заказчику снизить задержку в процессе принятия решения о выдаче кредитных продуктов. 

В перспективе заказчик хочет подгружать данные из отделений два раза в неделю. Для этого достаточно будет преобразовать процедуру (переписать DAG в части времени запуска — запускать дважды) и сформировать соответствующую процедуру бизнес-анализа.

Где можно использовать решение

Вариантов применения алгоритма великое множество. Даже просто меняя переменные кода можно многократно переиспользовать сценарий. Общий алгоритм сохранится и для любых других сходных манипуляций с отправкой пакетов файлов, блокнотов данных или скриптов по расписанию в BI-инструмент, например, в блокнот в Zeppelin. 

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

Как показывает наша практика, гибкость инструмента высокая, порог входа предельно низкий. Остальное зависит от вашей фантазии. Как ускорить рабочие процессы с 5 дней до 5 минут с помощью автоматизации рассказывали тут, а про другие кейсы — на сайте.