В этом посте — про разработку мобильного приложения для крупного коллекторского агентства, которое оказалось аркадой с новыми, все более сложными уровнями. По мере погружения в тему, набор применяемых технологий и требуемые компетенции росли как долг в МФО. Но теперь это приложение, возможно, лучшее, что есть на рынке. Заодно разработали мобильную CRM для выездных работников любых организаций — сотрудников точек продаж банков, участковых уполномоченных МВД, инспекторов Росгвардии при выездном контроле оборота оружия, для торговых агентов и мерчандайзеров, выездных техников Ростелекома, провайдеров Интернета, ремонтников ЖКХ.

О коллекторском бизнесе и что хотелось рассказать

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

Среди особенностей коллекторского бизнеса — соблюдение маржинальности, т.е. собранные средства должны покрывать деятельность коллекторского агентства, а сотрудники выездного взыскания получать вознаграждение за свою не всегда приятную работу, причем пропорционально результату. Возможность заметно повысить эффективность труда сотрудников «на выезде» за счет мобильного приложения — важная бизнес-задача, которую решила наша команда в этом проекте.

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

На этом ограничусь с введением в предметную область и расскажу, на каких технологиях мы сделали мобильное приложение «Выездной коллектор» и почему считаем его лучшим на рынке.

О предметной области выездного взыскания: кадры и технологии решают все

Понятно, что в коллекторы люди идут не по призванию «сеять разумное и доброе», а за заработком. Поэтому мы увидели свою задачу так — сделать мобильное приложение, которое сотрудники выездного взыскания будут воспринимать как инструмент для своего заработка, а не назойливого микро-менеджмента. 

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

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

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

С каким бэкграундом мы взялись за приложение для коллекторов

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

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

Собственно говоря, мобильное приложение для коллекторов — это был вызов для команды разработки CitConsulting и, как ни странно, для команды разработки БД Realm тоже, но об этом лучше рассказать в отдельном посте. 

Еще про опыт — команда прошла путь от разработки для серверов приложений (GlassFish, Tomcat, WebSphere, WildFly и множества других) до доработок OSGI- контейнеров (Servicemix / FuseESB, TalendESB, и, конечно же, Apache Karaf как модульной среды выполнения OSGi). Последние проекты были сделаны нами на Kubernetes. И да, мы не только умеем, но и контрибутим баг-фиксы.

Как мы составляли Feature List для приложения эффективного коллектора

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

Итак, что было неверно в самой идее существующих приложений для коллекторов? Все они смотрят на коллектора как на аналог курьера, за которым нужно ежеминутно следить и которому нужно все время давать указания, что же делать дальше. На самом деле коллектор – это умный и опытный переговорщик, которому нужны не указания, а совсем другое…

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

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

С появлением мобильного CRM-приложения у сотрудника выездного взыскания появляется вся информация на руках, чтобы показать клиенту документы по задолженности, обсудить возможные компромиссы по оплате, какие суммы платежей клиент считает подъемными для его/ее бюджета, и тут же оформить это документально.

Почему коллектор раньше был грубый и злой — у него мобильного приложения с карманной CRM не было )))

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

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

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

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

Результат по фитчам: что получилось

Команде разработчиков надо было пройти по тонкой грани между полнотой информации о клиентах на телефоне каждого коллектора (причем и в оффлайн тоже) и требованиями безопасников по минимизации риска утери сведений ввиду каких-либо намеренных или случайных утечек. А с утечками персональных данных и документов по клиентам регулятор в лице ФССП борется очень строго, вплоть до закрытия бизнеса.

В результате родился список основных фич, который принял вот такую форму:

• Просмотр списка клиентов с гибким фильтром поиска клиента/долга;

• Просмотр детальной информации о клиенте и структуре задолженности;

• Планирование выездов/контактов с клиентом;

• Построение маршрута по запланированным выездам;

• Просмотр/добавление документов по клиенту/договору (в т.ч. запись разговоров с клиентом) с приоритизацией выгрузки/загрузки;

• Просмотр «связей» клиента с другими лицами и клиентами;

• Просмотр истории контактов, обещаний и платежей по долгам;

• Добавление нового адреса/телефона/контакта по клиенту;

• Фиксация результата контакта после коммуникации с клиентом;

• Фиксация гео-координат контакта с клиентом (для последующей аналитики качества контакта);

• Прием платежей от клиента по карте;

• Просмотр сведений о вознаграждении/проделанной работе 

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

Отдельно нужно сказать о включении в состав приложения собственной функциональной «звонилки», которая завязана на БД в телефоне, может определять ФИО при входящем звонке от должника, ведет запись разговора и может переводить речь в текст, автоматом добавляет эту запись в историю контактов с должником.

Также звонилка завязана на общую историю звонков по каждому клиенту со всех устройств, чтобы не превысить разрешенное по ФЗ-230* число контактов в течение недели или иных промежутков времени. Штрафы от ФССП на коллекторские агентства за нарушение числа контактов очень приличные, т.к. накладываются по каждому нарушению отдельно.

*ФЗ-230 — коллекторский закон, требующий считать и не превышать число звонков, визитов, смс от организации, а значит нужно считать все коммуникации по всем системам и процессам, и ограничивать сотруднику коллекторского агентства доступ к клиенту при достижении порога.

Технологии для коллекторского приложения, как мы это себе представляли в ТЗ

Первое, что надо сделать было сделать — решить, как поддерживать актуальность данных на смартфоне каждого сотрудника выездного взыскания. Это более 500 МБ данных на каждого коллектора, для которых нужно обеспечивать актуальность (репликацию) с данными на сервере. Причем обновление данных должно происходить не по расписанию, а постоянно при наличии подключения к Интернету.

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

Мы ушли от понятия репликации, в приложении нет расписания по периодичности синхронизации данных. Когда есть Интернет, есть и проверка.

Для архитекторов и грамотных разработчиков задача обеспечить процесс поддержания актуальности данных решается без особых проблем — так у нас появилась Apache Kafka (https://kafka.apache.org — транзакционный лог для накопления изменений и минимизации нагрузки на БД), Graylog ( https://www.graylog.org) как сервер логирования всех систем и ошибок с мобильного приложения), Elasticsearch (одна из самых популярных поисковых систем в области Big Data, масштабируемое нереляционное хранилище данных с открытым исходным кодом).

Данные о клиентах предполагалось разместить в аналитической NoSQL-СУБД с широким набором функций полнотекстового поиска, которая позволяет быстро в режиме реального времени хранить, искать и анализировать большие объемы данных, плюс анализ логов никто не отменял. В итоге backend получился в формате High Availability Cluster на базе Kubernetes, где приложили все усилия, чтобы избежать ручного труда (отдельное спасибо GitOps).

Стек технологий для коллекторской мобилки

Из-за специфики отрасли, обновление данных не привязано к конкретному времени, данные живые, постоянно обновляются, и должны быть максимально быстро доставлены до сотрудника взыскания (не только ввиду требований 230-ФЗ по ограничению на число контактов). Это важно для оптимизации репликации — случалось, что оплата по долгу внесена, а у сотрудника это не отображается, поэтому происходит холостой выезд к клиенту. Особенно актуально, когда клиент в труднодоступном регионе – деревня, плохие дороги, etc.

В целом, основные требования по актуальности данных были весьма противоречивы — требовалась оперативность отображения информации и возможность работы приложения в оффлайн. Поэтому была выбрана архитектура MVI, на момент запуска проекта уже было четкое понимание, что у нас не будет состояния (snapshot) данных как такового, а будут потоки данных с их отображением на UI.

• БД на проекте — Realm, опять же на момент запуска это была одна из немногих БД с поддержкой шифрования и возможностью выполнения параллельных операций чтения/записи.

• Сетевой стек — здесь для обмена данными применяется собственный полнодуплексный протокол RSocket поверх TCP или WebSocket (в зависимости от среды развертывания) для обмена изменениями, позволяющий минимизировать объем передаваемого трафика и обеспечивающий стабильную работу приложения в мобильных сетях передачи данных. Для сокращения времени готовности приложения к первому использованию (до полной синхронизации) реализован алгоритм выбора приоритета передачи данных, учитывающий актуальные активности пользователя (его задачи, просматриваемые карточки клиентов и т.п.). Соединение защищено mTLS, при этом клиентские сертификаты выпускаются для каждой отдельной версии приложения, что позволяет одномоментно “отключить” дефектные (с точки зрения безопасности) версии приложения.

• Формат представления данных — AVRO (система сериализации данных, разработанная в рамках проекта Hadoop). Система использует JSON для определения структуры данных (схемы), которые сериализуются в компактный бинарный формат. Рассматривали и protoBuf (язык описания данных, предложенный Google, как альтернатива XML).

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

P.S. Рассматривались и gRPC, полнодуплексный HTTP/2 — но у фреймворка для удалённого вызова процедур gRPC единственным транспортом является protoBuf, а мы уже склонились выбрать AVRO. К слову, реализация полнодуплексного HTTP/2 на тот момент оставляла желать лучшего. 

О требованиях к смартфону и про установку приложения

Требования к смартфону на начало старта проекта были Android > 5.0 (из-за требований безопасности, т.к. в Android ниже пятой версии нельзя было использовать возможности по надежному хранению ключей шифрования в Android keyStore). Требования к самому «железу» были вполне скромные: оперативная память на устройстве от 512 МБ, хранилище 16 Гб, экран 800х600 и выше.

Требования по информационной безопасности разработанного ПО вполне допускали установку приложения на личные смартфоны сотрудников, т.е. не требовалось ограничивать доступ кроме как к каким-либо специфическим мобильным устройствам (например, только на корпоративные «мобилки», принадлежащие коллекторскому агентству).

Как это работает:

1. Сотрудник взыскания получает мобильное приложение (МП) по одному из каналов распространения (через ссылку/собственный канал дистрибьюции/MDM).

2. При установке МП запрашивает аутентификацию в Android KeyStore (необходимое условие для безопасного сохранения/использования криптографических ключей на устройстве), при отказе в аутентификации приложение не запустится.

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

4. Устройство устанавливает защищенное соединение с сервером (TLS v1.2+) с проверкой клиентского сертификата приложения.

5. При первой успешной авторизации с данного устройства на сервере регистрируется новое устройство (device id) и устанавливается связь с пользователем, который прошел авторизацию.

6. Далее доступны 3 сценария активации устройства:·       

   • автоматическая активация (в пределах ограничения на кол-во активных устройств), пользователь сразу получает данные и может работать с системой;

   • активация специалистом службы поддержки, по пользователю отображается информация о том, по какому каналу он должен обратиться в поддержку для активации приложения;

   • автоматическая активация (в пределах ограничения на кол-во активных устройств) с подтверждением по SMS-коду, высланному на устройство (с лимитом сообщений на уникальный номер телефона).

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

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

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

• функции управления пользователями и устройствами;

• доступ к техническому журналу использования приложения (авторизации, подключения, синхронизация, ошибки соединения);

• информацию о местоположении и пути перемещения авторизованных устройств;

• сведения о состоянии синхронизации данных с устройствами. 

Источником аутентификации и авторизации на сервере выступает корпоративная система заказчика (коллекторского агентства), основанная на LDAP, например MS Active Directory. Авторизация основана на членстве пользователей в группах LDAP. Поддерживается постоянная синхронизация состояния учетных записей, в том числе принудительная деактивация учетной записи через систему LDAP с последующим удалением данных на устройстве.

Про идею десктопной версии и почему она не была реализована

Отдельно надо сказать про идею десктопной версии в дополнение к МП – ведь коллектор может готовиться к выезду перед рабочим днем на компе с большим экраном (например, дома) и это удобнее.

На начальном этапе вариант с десктопом рассматривался и вот почему отказались — в качестве десктопной системы выступает сама коллекшн-система (очень большая и тяжелая ERP-система в агентстве), работающая как ведущая система (поставщик данных) по отношению к мобильному приложению.

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

Сотрудник службы взыскания также может запустить мобильное приложение на своем домашнем компьютере (Windows, Mac) в режиме эмуляции Android и пользоваться преимуществами большого экрана при подготовке к выезду.

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

Сделали, внедрили, результат оказался выше ожиданий —заказчик даже удивился

Вначале — о сроках внедрения мобильного приложения в коллекторском агентстве. Как показала практика, вполне можно уложиться в сроки до 12 недель. На начальном этапе это предпроектное обследование информационной системы заказчика, написание ТЗ, адаптация базовой версии МП под бренд заказчика. Затем идет установка серверной части (backend), интеграция с учетной системой заказчика, тестирование.

Что вызывало сложности — это обучение сотрудников коллекторского агентства по эффективному использованию приложения. Опыт работы с мобильными приложениями, возраст, обучаемость и адаптивность мышления у всех сотрудников разные. Поэтому здесь надо закладывать до 1 месяца на процесс обучения при условии работы с тренером (наставником) и адекватной техподдержкой, которые терпеливо объясняют пользователям функции приложения и помогают выполнить нужные действия.

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

Если говорить о изменениях в операционных результатах после внедрения приложения, то они, можно сказать, что превзошли ожидания заказчика. За счет наличия всей информации о должниках у себя в приложении, коллекторы перестали печатать документы в офисе, перестали ездить в офис, научились готовиться к выездам дома, составлять "выгодные" и оптимальные по времени маршруты, фиксировать контакты с должниками в МП, — т.е. работать со всей информацией вне офиса. Это дало увеличение объема успешного взыскания в среднем на 20%. 

Summary

Уникальность проекта в том, что получилась полноценная мобильная CRM для коллекторов с эффективным UX/UI. Доступно автоматическое формирование списка задач на выезд от сервера, с возможностью изменения списка задач руководителем. Более того, доступен и функционал самостоятельного формирования списка задач на выезд, которым могут воспользоваться опытные сотрудники.

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

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

Руководители коллекторских агентств, службы взыскания банков и МФО с помощью приложения получили возможность составить цифровой портрет рабочего дня сотрудника. При этом обеспечивается безопасность персональных данных должников без установки MDM, а базу данных Realm, начиная с версии 6.0 теперь можно нормально использовать на мобильных устройствах с ОС Android.

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