Омниканальные технологии обеспечивают банку лояльность клиентов, рост эффективности продаж и уменьшение себестоимости продажи (часть процесса продажи переносится в более дешевые каналы, действия по процессу не дублируются). Почему же не все банки могут воспользоваться этими технологиями? Как «работает» микросервисная архитектура и в чем ее преимущества? На каких ключевых моментах сосредоточиться при разработке микросервисной системы?
Принципиальное отличие омниканальности от мультиканальности в том, что процесс перехода от одного канала к другому плавный и каналы дополняют друг друга (рис. 1). При этом пользовательский опыт в разных каналах будет отличаться, так как возможность начать процесс (например, оформление кредита) в одном канале и завершить его в другом отсутствует.
R-Style Softlab,
департамент
онлайн-
решений,
начальник
аналитического
отдела
Как выглядит омниканальное банковское обслуживание для клиента
Клиент инициирует процесс, а банк, обеспечивая коммуникацию по удобным каналам и сохраняя единый пользовательский опыт, помогает ему оптимальным способом данный процесс пройти. Говоря о пользовательском опыте, мы имеем в виду, например, такую последовательность событий:
1. Клиент хочет получить кредит и заходит на сайт банка. Он начинает заполнять заявку, но по какой-то причине прерывает этот процесс на середине, оставив лишь ключевые данные (имя и номер телефона).
2. Через некоторое время с клиентом связывается оператор колл-центра и предлагает продолжить заполнение анкеты. Часть данных они вносят совместно, однако клиент торопится, времени не хватает, и они договариваются, что клиент придет в отделение.
3. Клиент приходит в отделение и завершает заполнение анкеты.
4. Если на рассмотрение заявки необходимо большое количество времени, клиент уходит и узнает результат рассмотрения в любом канале по выбору.
На первый взгляд может показаться, что процесс громоздкий, но на деле он требует минимальных временных затрат от клиента, который не заполняет одни и те же данные несколько раз. При этом клиент в любой момент и любое количество раз может прервать процесс, а банк ненавязчиво напомнит ему о заявке и доведет процесс до конца.
Звучит красиво и просто. Но почему же далеко не у всех банков получается использовать преимущества омниканальности?
Причины, по которым омниканальность доступна не всем
Чаще всего в банке установлено много ИТ-систем, которые закрывают свои задачи и взаимодействуют с клиентом по своему каналу: офис, ДБО, колл-центр (то самое мультиканальное обслуживание). И в каждой из них своя информация о клиенте, взаимоотношениях с ним и его продуктах. Банк «видит» несколько проекций (для каждого канала своя проекция) одного и того же клиента и иногда считает, что это разные люди. Есть решения, которые объединяют информацию о клиенте и таким образом формируют единый профиль, единую историю, единый продуктовый портфель. Но выполнить процесс по единым правилам эти системы все равно не могут. У каждой из них своя бизнес-логика, поэтому если начать процесс в одном из каналов и не закончить его, то в другом канале придется все начинать заново.
В то же время существуют решения, позволяющие в рамках одного процесса объединить несколько (обычно два-три) каналов взаимодействия с клиентом. Например, мастер-система по кредитным заявкам может делать выгрузку в CRM-систему, в результате недозаполненные на сайте банка заявки трансформируются в задачи на обзвон для сотрудников колл-центра. Эти решения обеспечивают определенные конкурентные преимущества, но не являются омниканальными, поскольку в других каналах (например, в ДБО) они уже не работают.
Микросервисная архитектура и ее преимущества
Систему, которая станет полностью омниканальной, можно создать на микросервисной архитектуре. Главный нюанс, который даст нам ту самую омниканальность, заключается в разделении презентационного слоя, слоя бизнес-логики и интеграционного слоя (рис. 2). При этом презентационный слой будет реализован для каждого из каналов в зависимости от их индивидуальных особенностей, а функциональная часть — только один раз. В нее входят системная часть (ядро, настройки, мониторинг и пр.), бизнес-логика (реализуется единым образом независимо от выполняемого процесса и канала) и канальная логика (реализуется для поддержки уникальных особенностей каждого канала). Таким образом, система работает единообразно и клиент получает одинаковый пользовательский опыт вне зависимости от канала обслуживания.
Использование микросервисной архитектуры даст еще пару преимуществ:
1. Банковские системы представляют собой сложный механизм, сочетающий в себе множество продуктов и услуг, за развитие которых отвечают разные подразделения, департаменты и команды специалистов. Важно, чтобы у них была возможность развивать и совершенствовать продукты и сервисы независимо друг от друга, а система позволяла им это делать. Такое бизнес-преимущество можно получить от использования гибкой системы, реализованной на микросервисной архитектуре.
2. Другим важным преимуществом является возможность быстро выводить на рынок новые продукты (сокращение time to market), позволяя продуктовым командам работать независимо друг от друга. Решения, построенные на монолитной архитектуре, могут тормозить этот процесс, поскольку для обновления какой-то отдельной функциональности приходится ждать обновления (нового релиза) всей системы.
Ключевые моменты разработки
Для создания системы нужно разработать:
— презентацию для каждого из каналов;
— интеграционный слой для взаимодействия с другими банковскими системами;
— системную часть;
— слой бизнес-логики.
Необходимо понимать, что функциональность, разработанная единожды в омниканальной системе, заменит ту же функциональность, работающую на момент внедрения в нескольких системах. Поэтому важно на этапе аналитики включить в проектную команду представителей бизнес-подразделений, технологов и других заинтересованных сотрудников банка. И еще: часто новая система становится максимально эффективной, если банк готов изменять устоявшиеся бизнес-процессы. Например, в одном из проектов нам удалось сократить время заведения нового клиента почти в 2 раза, а время открытия вклада — в 2,5 раза. Поэтому работы по оптимизации бизнес-процессов также необходимо учесть в плане проекта.
Теперь несколько слов о планировании и порядке разработки. Омниканальная система должна прийти на смену и постепенно вытеснить ряд систем, реализующих ту же функциональность. Процесс замены старой системы на новую бывает довольно длительным. В течение всего этого периода банк должен обеспечить непрерывное обслуживание клиентов. Поэтому важно спланировать процессы по разработке и обновлению ПО таким образом, чтобы внедрение отдельных блоков функциональности было выделено в самостоятельные законченные этапы.
При этом чтобы минимизировать риски отказа в обслуживании клиентов, нужно обеспечивать параллельную работу старой и новой функциональности (в старой и новой системах). Рациональным будет в первый этап включать самые востребованные операции, а в срок каждого этапа заложить не только период разработки и отладки, но и продолжительность опытно-промышленной эксплуатации, а также тиражирования. Каждый законченный блок функциональности для начала лучше обкатать на одном канале, а потом выводить в другие. Опыт показывает, что в качестве пилота лучше выбирать тот канал, в котором внедряемая функциональность используется по максимуму. Хороший пример такого канала — отделения банка.
Описанная схема — внедрение и тиражирование системы по частям — подразумевает значительные трудозатраты на отладку и опытно-промышленную эксплуатацию. Поэтому при реализации омниканальных решений необходимо использовать возможности автоматизированного тестирования. Это поможет быстрее выпускать новые продукты на рынок, повысить их качество и сократить количество ошибок. Разработка автотестов на первом этапе займет определенное время, однако эти затраты очень быстро окупятся. Не забывайте также про регулярное нагрузочное тестирование. Если вы работаете в разных регионах, то при тестировании необходимо учитывать влияние пропускной способности и загруженности каналов связи.
Чьими силами реализовать проект?
Этот вопрос часто возникает у тех, кто хочет внедрить омниканальное решение. Практика показывает, что на создание решения с нуля может уйти несколько лет, включая время на поиски и формирование команды востребованных на рынке специалистов. Другой вариант — привлечь к реализации вендора, имеющего готовую платформу, которая может быть адаптирована и интегрирована с инфраструктурой банка. Это может в лучшую сторону повлиять на сроки и стоимость проекта, но есть вероятность получить риски, связанные с зависимостью от разработчика.
В последнее время становится популярным еще один вариант — совместная разработка системы вендором и сотрудниками банка. Обычно на первых этапах основной объем работ выполняет вендор. Специалисты банка берут на себя задачи, в которых они обладают высоким уровнем экспертизы, либо занимаются разработкой презентационного слоя для ряда каналов.
Со временем можно уменьшить долю задач вендора и даже полностью перейти на развитие системы силами банка. Таким образом, банк получит экономию на старте и сможет влиять на сроки проекта и скорость разработки, а также снизит риски, связанные с зависимостью от вендора.
Комментарий
Автор делает абсолютно справедливые утверждения о преимуществах омниканальной философии взаимодействия перед мультиканальной. Тем не менее, статья скорее отвечает на вопрос о преимуществах микросервисной архитектуры над монолитной в банковском ИТ-ландшафте.
Причем омниканальность — не прямое следствие микросервисного подхода. Есть и другие его преимущества: от готовности к горизонтальному масштабированию до возможности даже развивать разные микросервисы, используя разные технологические стеки. На рынке известны кейсы, когда продуктовые микросервисы на JAVA живут бок о бок с микросервисами на .NET core. Омниканальность как желаемый эффект для customer journey иногда вполне достижима уже в случае разделения слоев представления, интеграции и бизнес-логики при трансформации дистанционного канала с реализацией бесшовных механик в доавторизационной и послеавторизационной зонах.
Омниканальность дают не конкретное ПО, не команда, не микросервисный подход: это прежде всего коммуникационная философия.
Тем не менее, если смотреть на архитектурный подход, который описывает автор, как на green field, то сложно чему-либо возразить. Все абсолютно верно и академично.
Однако реалии банковских трансформаций таковы, что вклад legacy инфраструктуры в слое core banking является превалирующим. Поэтому, как правило, за омниканальность в большинстве рыночных кейсов отвечают больше фронтальный и интеграционный слои, для которых также применимы микросервисные подходы.
Чтобы описанная концепция была максимально воплощаема в жизнь и была возможность формировать механики продолженного взаимодействия в любом канале, фронт-офис сотрудника должен быть расширенной версией клиентского канала.
До тех пор, пока это не так, можно иметь горизонтальную омниканальность для конечного клиента и вертикальную мультиканальность в подразделениях банка с потребностью интегрировать «всё со всем».
Источник: Регламент Банк
