Постоянный рост конкуренции среди Банков заставляет подстраиваться под разные категории Клиентов. Так, одним проще зайти на сайт и оформить заявку на банковский продукт онлайн, другие же привыкли выбирать новые продукты и услуги непосредственно при живом общении с банковским представителем. В сентябре 2019г. в Хоум Кредит Банке решили запустить новый процесс для Клиента, основная цель которого была в сохранении контакта «Клиент – Оператор Банка» и отказе от физической привязки оператора к офису или стойке Банка в торговом центре.
Дата запуска пилотного проекта была назначена на начало декабря 2019 года. Для его реализации в кратчайшие сроки нужно было разработать систему с функционалом оформления именной и неименной дебетовой карты для новых и существующих Клиентов Банка.
Стали смотреть в сторону планшетного решения. Реализация нового процесса на планшете на базе архитектуры текущей фронт-офисной системы Банка для работы Операторов с Клиентом выглядела нерациональной по причине устаревшего технологического стека, т.к. текущий фронт-офис представляет собой монолитное web- приложение, написанное 8 лет назад на Silverlight. Попытки работы с текущим фронтом на планшете были не успешными из-за перегруженной ui-части приложения и отсутствия адаптивной вёрстки. Кроме того, отсутствие поддержки Silverlight со стороны Microsoft тонко намекало на то, что жизненный цикл нашего текущего приложения подходит к концу и что наступил момент радикальной переработки и переход на новые технологии. Пришли к решению реализации микросервисной архитектуры. Почему было необходимо отказаться от монолита? Во-первых, из-за масштабируемости решения, улучшения общей отказоустойчивости и независимого обновления компонентов. Во-вторых, в Банке тенденция распределения функционала между продуктовыми командами и микросервисный подход дает в этом случае большую гибкость и независимость команд. На первых этапах для пилотного проекта выделили следующие домены (микросервисы): пользователь, клиент, дебетовая карта и инцидент. Для создания back-части приложения использовали платформу .Net Core 2.2 (недавно перешли на 3.0), позаимствовав элементы бизнес-логики из легаси системы. Фронт-часть было решено строить, используя react.
Параллельно с определением архитектуры обсуждались интерфейс приложения и бизнес-логика процесса. Требовалось определить, как Оператор будет взаимодействовать с Клиентом, какой необходим пакет документов, какая информация нужна Оператору на каждом конкретном шаге продажи. Целью было упрощение текущего бизнес-процесса, а не простое копирование функционала на новую платформу. Так в новом решении было сокращено количество полей при заведении заявки на дебетовую карту и исключен этап анкетирования Клиента (сбор информации о том, откуда Клиент узнал о Хоум Кредит Банке). На главную страницу с клиентскими данными добавилась функция быстрого доступа к оформлению приоритетных дебетовых продуктов. А на этапе одобрения заявки отобразили развернутую информацию о тарифах и условиях по продукту, которая так же помогала Оператору.
За 8 лет на продуктивной среде главная страница фронт-офиса с данными Клиента и функционалом подключения продуктов и услуг стала чересчур перегруженной из-за бесконечных иконок и полей.
Хотелось добавить «воздуха» в интерфейс. Тут пришлось расставить приоритеты, определив какой функционал нужен Операторам в первую очередь для доступа на главной странице, какой можно отобразить на боковой панели, а от чего можно отказаться из-за ненадобности (да, да! такие поля нашлись). В результате плодотворной работы команды с дизайнером были спроектированы первые эскизы страницы с клиентскими данными и страницы с этапами заведения заявки на дебетовую карту.
База знаний на текущий фронт-офис «живет» в Word с совместным редактированием в SharePoint. В новом проекте решили пилотировать новый процесс ведения документации в Confluence в связке со Swagger для автодокументирования. Наш путь перехода, плюсы и минусы выбранного решения будут описаны в отдельной статье. Скажу только, что тема выбора инструмента ведения требований до сих пор открыта, мы находимся на стадии поиска оптимального решения по поддержанию документации в актуальном состоянии с минимальным вложением ресурсов.
В итоге вот так выглядела наша дорожная карта на пути к запуску заветного пилота.
Успеть к дедлайну пилота помогла выстроенная система взаимодействия в команде. На старте проекта команде пришлось отказаться от waterfall и ступить на тропу Agile. Это был адаптированный Agile нашей команды. Мы распараллелились: разработчики стартовали на стадии договоренностей с командой о реализации, которая обычно до начала разработки отражается в требованиях и согласовывается со всеми участниками процесса. Открытые вопросы обсуждались на встречах. Решения принимались командой сообща. В любой момент времени каждый участник команды мог рассказать о статусе проекта, все чувствовали себя вовлеченными в процесс и с нетерпением ждали пилота по результатам нашей работы.
Пилот проходил в одном из крупнейших ТЦ Москвы в преддверии Нового Года. Для пилотного проекта были наняты новые специалисты по продажам, которые не знали банковских продуктов и не работали до этого с нашей текущей фронт-офисной системой. Результаты пилота показали, что новые Пользователи без труда разобрались с необходимой последовательностью действий в нашем новом приложении, а это означало что по такой схеме можно было запускаться на других площадках, набирая новых специалистов с минимальными требованиями.
В новом приложении мы смотрели в сторону постоянного обновления функционала на продуктиве, исходя из потребностей Операторов и Клиентов. Так в первую неделю запуска выпустили 25 небольших доработок по результатам пилота. Например, в пакет документов при оформлении договора добавили печатную форму с тарифами по продукту, т.к. большинство Клиентов, просмотрев тарифы на планшете у Оператора, изъявляли желание получить распечатанные тарифы «на руки».
За активностью продаж через новую платформу следили онлайн через отчет на Graphana и радовались каждому новому подписанию договора.
В текущем фронт-офисе, при разборе продуктовых ошибок, есть проблема — не всегда удается восстановить последовательность действий Оператора, особенно в случаях, когда существуют непредсказуемые переходы между экранами приложения (выявленные постфактум), которые не заложены в бизнес-логику процесса. Обращение к Пользователю как правило безрезультатно, т.к. из-за большого клиентопотока невозможно восстановить последовательность совершенных в приложении действий с конкретным Клиентом в конкретный момент времени. В новой системе хотелось решить и эти проблемы. Сквозное логирование по всем микросервисам в рамках Сессии Клиента и Оператора, дополнительная запись в лог текстовых сообщений при каждом действии Оператора (создал нового Клиента, подписал договор, подключил sms-информирование) и полный скриншот экрана помогли быстро восстановить картину бизнес-процесса, ускорив разбор продуктовых ошибок при просмотре логов в GrayLog.
Целью пилота было не только реализовать планшетное решение, но и заложить основы для нашей будущей платформы фронт-офисной системы Хоум Кредит Банка. Сейчас мы продолжаем совершенствоваться. В работе активность по добавлению нового модуля «Кредиты» для работы с кредитными продуктами Банка. И так же в процессе исследование применения новых технологий (graphql, цель которого не гонять лишние данные с бэка на фронт; camunda для гибкой настройки бизнес-процесса; Prometheus для сбора бизнес-метрик для построения отчетов).
В дальнейшем видим продвижение планшетного решения путём добавления функционала продаж различных типов банковских продуктов. Сейчас в приоритете создание процесса оформления кредитной карты Банка. Плюс расширение зоны применения планшета на магазины электроники и представительства пенсионных фондов.
Дата запуска пилотного проекта была назначена на начало декабря 2019 года. Для его реализации в кратчайшие сроки нужно было разработать систему с функционалом оформления именной и неименной дебетовой карты для новых и существующих Клиентов Банка.
На пути к новой платформе
Стали смотреть в сторону планшетного решения. Реализация нового процесса на планшете на базе архитектуры текущей фронт-офисной системы Банка для работы Операторов с Клиентом выглядела нерациональной по причине устаревшего технологического стека, т.к. текущий фронт-офис представляет собой монолитное web- приложение, написанное 8 лет назад на Silverlight. Попытки работы с текущим фронтом на планшете были не успешными из-за перегруженной ui-части приложения и отсутствия адаптивной вёрстки. Кроме того, отсутствие поддержки Silverlight со стороны Microsoft тонко намекало на то, что жизненный цикл нашего текущего приложения подходит к концу и что наступил момент радикальной переработки и переход на новые технологии. Пришли к решению реализации микросервисной архитектуры. Почему было необходимо отказаться от монолита? Во-первых, из-за масштабируемости решения, улучшения общей отказоустойчивости и независимого обновления компонентов. Во-вторых, в Банке тенденция распределения функционала между продуктовыми командами и микросервисный подход дает в этом случае большую гибкость и независимость команд. На первых этапах для пилотного проекта выделили следующие домены (микросервисы): пользователь, клиент, дебетовая карта и инцидент. Для создания back-части приложения использовали платформу .Net Core 2.2 (недавно перешли на 3.0), позаимствовав элементы бизнес-логики из легаси системы. Фронт-часть было решено строить, используя react.
UI/UX
Параллельно с определением архитектуры обсуждались интерфейс приложения и бизнес-логика процесса. Требовалось определить, как Оператор будет взаимодействовать с Клиентом, какой необходим пакет документов, какая информация нужна Оператору на каждом конкретном шаге продажи. Целью было упрощение текущего бизнес-процесса, а не простое копирование функционала на новую платформу. Так в новом решении было сокращено количество полей при заведении заявки на дебетовую карту и исключен этап анкетирования Клиента (сбор информации о том, откуда Клиент узнал о Хоум Кредит Банке). На главную страницу с клиентскими данными добавилась функция быстрого доступа к оформлению приоритетных дебетовых продуктов. А на этапе одобрения заявки отобразили развернутую информацию о тарифах и условиях по продукту, которая так же помогала Оператору.
За 8 лет на продуктивной среде главная страница фронт-офиса с данными Клиента и функционалом подключения продуктов и услуг стала чересчур перегруженной из-за бесконечных иконок и полей.
Хотелось добавить «воздуха» в интерфейс. Тут пришлось расставить приоритеты, определив какой функционал нужен Операторам в первую очередь для доступа на главной странице, какой можно отобразить на боковой панели, а от чего можно отказаться из-за ненадобности (да, да! такие поля нашлись). В результате плодотворной работы команды с дизайнером были спроектированы первые эскизы страницы с клиентскими данными и страницы с этапами заведения заявки на дебетовую карту.
Документация
База знаний на текущий фронт-офис «живет» в Word с совместным редактированием в SharePoint. В новом проекте решили пилотировать новый процесс ведения документации в Confluence в связке со Swagger для автодокументирования. Наш путь перехода, плюсы и минусы выбранного решения будут описаны в отдельной статье. Скажу только, что тема выбора инструмента ведения требований до сих пор открыта, мы находимся на стадии поиска оптимального решения по поддержанию документации в актуальном состоянии с минимальным вложением ресурсов.
В путь!
В итоге вот так выглядела наша дорожная карта на пути к запуску заветного пилота.
Успеть к дедлайну пилота помогла выстроенная система взаимодействия в команде. На старте проекта команде пришлось отказаться от waterfall и ступить на тропу Agile. Это был адаптированный Agile нашей команды. Мы распараллелились: разработчики стартовали на стадии договоренностей с командой о реализации, которая обычно до начала разработки отражается в требованиях и согласовывается со всеми участниками процесса. Открытые вопросы обсуждались на встречах. Решения принимались командой сообща. В любой момент времени каждый участник команды мог рассказать о статусе проекта, все чувствовали себя вовлеченными в процесс и с нетерпением ждали пилота по результатам нашей работы.
Пилот
Пилот проходил в одном из крупнейших ТЦ Москвы в преддверии Нового Года. Для пилотного проекта были наняты новые специалисты по продажам, которые не знали банковских продуктов и не работали до этого с нашей текущей фронт-офисной системой. Результаты пилота показали, что новые Пользователи без труда разобрались с необходимой последовательностью действий в нашем новом приложении, а это означало что по такой схеме можно было запускаться на других площадках, набирая новых специалистов с минимальными требованиями.
В новом приложении мы смотрели в сторону постоянного обновления функционала на продуктиве, исходя из потребностей Операторов и Клиентов. Так в первую неделю запуска выпустили 25 небольших доработок по результатам пилота. Например, в пакет документов при оформлении договора добавили печатную форму с тарифами по продукту, т.к. большинство Клиентов, просмотрев тарифы на планшете у Оператора, изъявляли желание получить распечатанные тарифы «на руки».
За активностью продаж через новую платформу следили онлайн через отчет на Graphana и радовались каждому новому подписанию договора.
Ошибки
В текущем фронт-офисе, при разборе продуктовых ошибок, есть проблема — не всегда удается восстановить последовательность действий Оператора, особенно в случаях, когда существуют непредсказуемые переходы между экранами приложения (выявленные постфактум), которые не заложены в бизнес-логику процесса. Обращение к Пользователю как правило безрезультатно, т.к. из-за большого клиентопотока невозможно восстановить последовательность совершенных в приложении действий с конкретным Клиентом в конкретный момент времени. В новой системе хотелось решить и эти проблемы. Сквозное логирование по всем микросервисам в рамках Сессии Клиента и Оператора, дополнительная запись в лог текстовых сообщений при каждом действии Оператора (создал нового Клиента, подписал договор, подключил sms-информирование) и полный скриншот экрана помогли быстро восстановить картину бизнес-процесса, ускорив разбор продуктовых ошибок при просмотре логов в GrayLog.
Планы на будущее
Целью пилота было не только реализовать планшетное решение, но и заложить основы для нашей будущей платформы фронт-офисной системы Хоум Кредит Банка. Сейчас мы продолжаем совершенствоваться. В работе активность по добавлению нового модуля «Кредиты» для работы с кредитными продуктами Банка. И так же в процессе исследование применения новых технологий (graphql, цель которого не гонять лишние данные с бэка на фронт; camunda для гибкой настройки бизнес-процесса; Prometheus для сбора бизнес-метрик для построения отчетов).
В дальнейшем видим продвижение планшетного решения путём добавления функционала продаж различных типов банковских продуктов. Сейчас в приоритете создание процесса оформления кредитной карты Банка. Плюс расширение зоны применения планшета на магазины электроники и представительства пенсионных фондов.