Как мы автоматизировали мониторинг статусов ипотечных заявок для клиента
Эксперты ИТ-компании SimbirSoft расскажут, как для одного из клиентов оптимизировали мониторинг оформления и изменения статусов ипотечных заявок![Как мы автоматизировали мониторинг статусов ипотечных заявок для клиента](https://pics.rbc.ru/v2_companies_s3/resized/960xH/media/company_press_release_image/8bb91e1e-77d3-44f0-a16b-60c59b677c65.jpg)
Задача:
Автоматизировать обновление данных о полученных ипотечных заявках из отделений — с еженедельным обновлением.
Причина:
Чтобы получить отчетность, заинтересованным лицам нужно было проводить много ручных операций. Это объективно неудобно и затратно по времени. Но эти отчеты требовались для принятия решений о выдаче кредитных продуктов.
В современном банковском мире компании активно ищут способы упростить и ускорить процессы. В этом кейсе расскажем, как мы оптимизировали мониторинг оформления ипотечных заявок и изменения их статусов на одном из проектов.
Статья будет полезна руководителям, которые хотят упростить мониторинг процессов и результатов в своих направлениях, а также аналитикам, желающим узнать, как настроить автоматическое обновление отчетности.
Какая задача стояла
Исходная ситуация. Ипотечные заявки оформляются в отделениях банка или дистанционно через бэк-офис. Есть дашборд в 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, который выполнял следующие задачи:
- Получение данных с сервера: созданный скрипт забирал данные с сервера за предыдущую неделю и сохранял их в соответствующую папку.
- Проверка содержимого файла с отображением его в логах для гарантированного сохранения корректной информации и раннего предупреждения о сбоях.
- Создание и проверка таблицы в базе данных: еще несколько задач внутри создавали таблицу в базе данных, если она еще не была создана. Далее проверяли ее состояние и выдавали подробную информацию о ней для возможной диагностики.
- Загрузка данных в базу: скрипт принимал файл из первой задачи по указанному пути, обрабатывал и загружал данные в базу данных, переименовывая поля и заполняя пропуски.
Фактически с помощью простого скрипта мы полностью автоматизировали процесс подготовки и обработки данных с промежуточной проверкой, исключив ручной труд и соответствующие погрешности исполнителей. Повышение точности и скорости обработки позволило, в свою очередь, устранить длительные периоды обработки, необходимость дополнительной трудоемкой проверки данных вышестоящими сотрудниками и перераспределить рабочие задачи в пользу анализа данных из CRM.
![Как мы автоматизировали мониторинг статусов ипотечных заявок для клиента](https://pics.rbc.ru/v2_companies_s3/media/news_body_images/feb67907-9833-4d41-8575-8d16242726f6.jpg)
С какими трудностями столкнулись
Не все прошло так гладко, как могло показаться. В процессе работы мы столкнулись с несколькими трудностями. Во-первых, получение необходимых доступов заняло больше времени, чем мы ожидали. Эта задержка была вызвана особенностями финтех-сферы. Мы рекомендуем закладывать больше времени на этот этап, чтобы избежать задержек в реализации проекта.
Во-вторых, требования к итоговым отчетам несколько раз изменялись. Это приводило к необходимости внесения корректировок в уже настроенные автоматизированные процессы. Поэтому всем, кто решит пойти тем же путем, рекомендуем заранее закладывать достаточную гибкость в настраиваемые процессы, чтобы оставить себе возможность для их изменения в будущем и не затягивать сроки реализации.
Кроме того, настройка DAG требовала тщательного планирования времени запуска. Мы посчитали, что запуск DAG за 3-4 часа до начала рабочего дня будет оптимальным, чтобы данные успевали обновляться и были готовы к использованию утром. Однако из-за большого объема данных процесс загрузки мог затянуться. После нескольких итераций мы нашли другое оптимальное время для запуска и смогли обеспечить своевременное обновление отчетов.
Какие результаты получили
Инструменты дата-анализа позволили увеличить производительность по предварительной обработке данных практически в 9 раз, единовременно затратив 16 часов работы дата-аналитика.
Ранее данные из отделений загружались в течение понедельника, и только спустя двое-трое суток непрерывной обработки руководство получало информацию о статусах заявок за предыдущую неделю. Теперь вся предварительная работа с данными занимает не более 8-12 часов и происходит в ночное, нерабочее время. Утром следующего рабочего дня после старта их обработки данные уже можно анализировать. Это позволило снизить объем рутины в работе аналитиков и задержку при принятии решений о выдаче кредитов.
![Как мы автоматизировали мониторинг статусов ипотечных заявок для клиента](https://pics.rbc.ru/v2_companies_s3/media/news_body_images/1455e946-a409-40e2-ab79-67afa6dd7dbb.jpg)
Данные автоматически поступают в хранилище и используются для дальнейшего анализа. Информация из CRM-систем всех отделений обрабатывается и сохраняется в PostgreSQL, формируя витрину данных. Витрина подключена к Power BI, в котором система строит дашборды и по мере поступления новых данных автоматически их обновляет.
В результате мы запустили и отладили работу DAG в интерфейсе, настроили подключение к базе данных в Power BI, ввели нужные параметры, выбрали таблицу и все — на этом работа по предварительной обработке данных завершена. Бизнес-аналитик и руководство могут заниматься своей работой, анализировать конкретные цифры о платежеспособности клиентов и рисках. Так мы помогли заказчику снизить задержку в процессе принятия решения о выдаче кредитных продуктов.
В перспективе заказчик хочет подгружать данные из отделений два раза в неделю. Для этого достаточно будет преобразовать процедуру (переписать DAG в части времени запуска — запускать дважды) и сформировать соответствующую процедуру бизнес-анализа.
Где можно использовать решение
Вариантов применения алгоритма великое множество. Даже просто меняя переменные кода можно многократно переиспользовать сценарий. Общий алгоритм сохранится и для любых других сходных манипуляций с отправкой пакетов файлов, блокнотов данных или скриптов по расписанию в BI-инструмент, например, в блокнот в Zeppelin.
Также его можно использовать также для сбора обновления содержания контента на сайтах через базу данных с целью обработки, последующего вывода необходимой информации и ее анализа — вплоть до премодерации недопустимого контента, например, для определения пользователей с некорректными отзывами.
Как показывает наша практика, гибкость инструмента высокая, порог входа предельно низкий. Остальное зависит от вашей фантазии. Как ускорить рабочие процессы с 5 дней до 5 минут с помощью автоматизации рассказывали тут, а про другие кейсы — на сайте.
В результате разработанное решение помогло снизить задержку при принятии решений о выдаче кредитных продуктов, уменьшить техническую рутину в работе аналитиков и увеличить производительность отдела по предварительной обработке данных практически в 9 раз.
Источники изображений:
Freepik.com
Интересное:
Новости отрасли:
Все новости:
Публикация компании
Профиль
Социальные сети