Второй шаг создания экосистемы

Что такое банковская экосистема?

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

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

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

Ограничения со стороны front-end существующих систем ДБО

Как известно, все чаще пользователями систем ДБО становятся люди, относящиеся к поколению Х и миллениалам. Это влечет за собой изменение требований со стороны пользователей к интерфейсам, к удобству работы и набору сервисов, представленному в дистанционных каналах.

Еще недавно, 5‑7 лет назад, банки были нацелены на обслуживание крупных корпоративных клиентов или компаний сегмента Friends and Family. Очень часто в таких случаях удобство интерфейса было практически на последнем месте в списке приоритетов, на которые клиент опирался при выборе банка. Кредитные организации использовали «типовой» дизайн от разработчика, перекрашивая его в свои корпоративные цвета. Немногие банки заказывали UX-исследование своих интерфейсов и их последующую переработку, а те немногие, которые были готовы выполнить кастомизацию, сталкивались с ограничениями front-end существующих систем ДБО. Нередко желание иметь новые интерфейсы выливалось в необходимость создания с нуля нового front-end силами разработчика ДБО.

Еще одной проблемой является то, что front-end системы ДБО един для всех сегментов клиентов. Отсутствие Open API ограничивает банк в возможности создания нескольких front-end для отдельных сегментов клиентов, например, для предприятий малого бизнеса.

«Монолитность» систем. Сложность и длительность разработки нового функционала

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

При этом в большинстве банков используются «коробочные» системы ДБО, разработанные 5‑10 лет назад, устаревшие как функционально, так и технологически. Реализация нового функционала требует длительных процедур согласования доработки для включения ее в «коробку» и еще более долгого ожидания реализации доработки вендором. Сам же банк не может вести самостоятельную разработку и внедрение новых бизнес-требований из-за ограничений системы и вендора. Дополнительно, после реализации доработок вендором, банк вынужден проводить не менее длительные процедуры тестирования всей обновленной системы, поскольку в большинстве случаев «коробочные» решения являются «монолитными» и имеют множество ограничений, присущих такого рода системам.

Стоит отметить, что web- и мобильные приложения развиваются отдельно друг от друга, разными командами внутри вендора, а очень часто — и разными вендорами. Банк вынужден выбирать и реализовывать функционал в одном из каналов или платить за доработку несколько раз для реализации в разных клиентских приложениях (web, мобильные приложения и т. д.). Безусловно, все это отрицательно сказывается на сроках ввода нового функционала, и реальный time-to-market не отвечает быстроменяющимся требованиям рынка.

Отсутствие возможности работы с клиентами по H2H

Как правило, крупные корпоративные клиенты не хотят использовать систему ДБО банка для выполнения повседневных задач, подписания платежных документов, заявок, получения выписок и т. д. У таких клиентов есть свои собственные ERP-системы, в которых они ведут финансовый учет и готовы вести взаимодействие с банком. Сегодня лишь единицы кредитных организаций готовы предоставить таким клиентам функционал прямого взаимодействия ERP-системы с системами банка host-to-host (H2H). Это напрямую связано с тем, о чем мы упоминали выше: банки используют устаревшие системы ДБО, которые не обладают открытыми API для клиентских приложений, и потому вынуждены заказывать сложные интеграционные проекты для подключения каждого клиента.

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

Взаимодействие через Н2Н между клиентом и банком будет набирать популярность, несмотря на то, что многие банки при таком взаимодействии видят риск потери дополнительного канала кросс-­продаж своих продуктов. Рынок меняется очень быстро, и через некоторое время возникнет риск полной потери клиента из-за непредоставления ему удобного сервиса. На наш взгляд, нет необходимости искусственно заводить клиентов в систему ДБО. Клиенту необходимо предоставить удобный сервис, повысить его лояльность, что в свою очередь положительно повлияет на возможность продажи клиенту дополнительных услуг.

Сложность масштабирования
 

Многие текущие системы банков, включая ДБО, как мы уже отметили выше, построены по принципу «монолитных» систем и имеют множество ограничений, в том числе в части масштабирования. Сейчас в случае достижения пика производительности кредитная организация вынуждена поднимать еще одну копию систем ДБО. Для этого банку требуется покупать дополнительные серверные лицензии на систему ДБО и «железо», а также организовать дополнительное администрирование приложений. Это очень длительный, трудоемкий и ресурсоемкий процесс. Использование систем, построенных на микросервисной архитектуре [Микросервисная архитектура — вариант сервис-ориентированной архитектуры ПО, подразумевающий отказ от единой, монолитной структуры и направленный на взаимодействие, насколько это возможно, небольших, слабо связанных и легко изменяемых модулей — микросервисов], позволяет банку без лишних финансовых и временных затрат, без выделения человеческих ресурсов построить отказоустойчивое решение, готовое к горизонтальному масштабированию практически «по щелчку мыши».

Переход на новую систему ДБО

Сегодня нередки проекты по переходу от одного вендора ДБО к другому или по обновлению ДБО на «новую версию» в рамках одного вендора. Однако мы видим, что банки, внедряя новую систему, по сути внедряют продукт, разработанный 5‑7 и больше лет назад. Для полного перехода на новую систему требуется 2‑3 года. В результате получается, что банк выводит в эксплуатацию систему 10‑летней давности, которая по понятным причинам устарела морально, технически и функционально. Распространенный пример проектов по обновлению, который мы часто встречаем, — это проекты, которые заявлены производителем ДБО как обновление и переход на новую версию системы, при этом «старая» и «новая» системы, как правило, не отличаются архитектурой и структурой данных, однако даже такой проект длится более полутора-двух лет. Положа руку на сердце, можно с уверенностью сказать, что проект по обновлению не может и не должен длиться столько времени, а то, что заявлено как обновление, является не чем иным, как простым переходом на новую версию ДБО в рамках одного вендора, с перспективой получения множества проблем и ограничений.

Связь технологий и бизнеса

Итак, мы рассмотрели несколько основных проблем, с которыми сталкиваются банки, но далеко не полный их список. Технологии, подходы в разработке, внедрении проектов и развитии продуктов за последние несколько лет шагнули далеко вперед относительно подходов 5‑7‑летней давности. В большинстве банков встречается то или иное сочетание указанных выше проблем, и это крайне отрицательно сказывается на развитии ими своих дистанционных сервисов, на возможностях добиваться повышения лояльности клиентов и, конечно же, на перспективах получения дополнительного дохода.

Представители бизнеса могут, конечно, сказать: «ну, а какое нам дело до микросервисов, API и т. д. Пусть И Т разбирается с этими проблемами, нам нужно деньги зарабатывать». При этом они будут отчасти правы, а отчасти — нет. Связь между технологиями и бизнесом видна не сразу, поэтому продемонстрируем ее на нескольких примерах.

В предыдущей публикации мы говорили о роли личного кабинета для привлечения и онбординга банковских клиентов. Однако на этом миссия ЛК не заканчивается. Так, в платформе Salto разработки компании JTC системы front-end и back-end реализованы независимо друг от друга, а их взаимодействие построено на использовании Open API. Такой подход позволяет решить сразу несколько задач и нивелировать ряд описанных проблем:

• Создание единого фронтального клиентского приложения для множества систем банка, в которых работает клиент (БСК, ВЭД, ДБО, ВК и т. д.), по принципу «единого окна». В этом случае мы говорим не о создании некого суперприложения с множеством функций (хотя это является трендом последних лет), но о создании условий для сквозной аутентификации из ЛК в другие системы, а также для унификации UX и UI. Иными словами, в результате такого подхода пользователь (с точки зрения банка) работает в разных back-end системах, при этом сам он использует единый клиентский интерфейс, что, естественно, улучшает его клиентский опыт и повышает лояльность к банку.
• Создание нескольких фронтальных приложений для разных клиентских сегментов и предоставление в них разных наборов сервисов и функций в зависимости от потребностей клиентов. Такой подход позволяет банку предоставить клиентам — представителям малого и микробизнеса — клиентское приложение с уникальным набором банковских и партнерских сервисов, например, онлайн-­бухгалтерию, эквайринг и РКО, и более ничем не нагружать интерфейс. Это предложение наверняка вызовет интерес у клиентов из сегмента микробизнеса, а для крупных клиентов набор может быть гораздо более широким как в части банковских, так и в части партнерских услуг. При таком подходе становится возможной сегментация не только на уровне банка, но и на уровне визуального оформления клиентских приложений. Однако важно еще раз подчеркнуть — реализация подобной задачи возможна с использованием одной back-end системы ДБО.
• Создание агентских приложений для массового привлечения клиентов. Создание отдельного интерфейса агента (чаще всего это копия интерфейса сотрудника банка с ограниченными правами и измененным UI) позволяет агентам быстро и эффективно начать взаимодействовать с банком, что в свою очередь ускоряет процесс взаимодействия агентов с клиентами. Ведь зачастую агенты несколько раз в день выгружают excel-­файлы с лидами, что приводит к необходимости сотрудникам банка вручную обрабатывать входящий поток информации, исправлять ошибки и т. д. Это сильно вредит лидогенерации и скорости взаимодействия с клиентом. При наличии же у агента интерфейса лид поступает в банк уже после прохождения всех проверок, с выверенной информацией, и банковскому сотруднику необходимо только связаться с клиентом и совершить сделку. А в ряде случаев, например, при резервировании счетов, процедура происходит даже без участия сотрудника банка.
• Возможность самостоятельно создавать новые клиентские приложения (web, мобильные, устройства самообслуживания). Ресурсы практически любого вендора ограниченны, и не каждый вендор может предоставить свободную команду для реализации проекта в необходимые для банка сроки. Наличие инструмента независимой разработки полностью развязывает банку руки в вопросе выбора вендора для реализации той или иной задачи в конкретный момент времени.

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

В начале статьи мы подчеркнули, что банковская экосистема — это вовсе необязательно умные колонки, голосовые помощники и нетипичные для банка сервисы в виде такси и т. д. Экосистема — прежде всего набор современных ИТ-инструментов, за счет которых банк сможет в минимальные сроки создавать и выводить на рынок новые продукты, сервисы, клиентские приложения в режиме time-to-market.

В банковском сообществе сложилось мнение, что проект, в котором так или иначе фигурирует слово «экосистема», это либо дорого, либо долго, или все вместе. Наша компания разработала уникальную, не имеющую аналогов на рынке платформу Salto, на базе которой и реализует проекты в области экосистем, ДБО и ЭДО. Наш опыт показывает, что внедрение базовых механизмов платформы Salto уже через 3‑5 месяцев позволяет банку реализовать сервис сквозной аутентификации со всеми существующими клиентскими системами, запустить новое клиентское приложение, например, личный кабинет, и предоставить клиенту возможность работы в одном окне. Даже такой минимальный набор позволяет банку в сжатые сроки и с минимумом затрат предоставить клиенту новый и удобный сервис. В свою очередь банк получает мощный механизм и платформу, на базе которых он, самостоятельно или привлекая команду JTC, может начать постепенное выстраивание абсолютно новой и современной системы дистанционного обслуживания. При этом хочу еще раз подчеркнуть — в большинстве случаев это не требует смены существующей в банке системы ДБО. Шаг за шагом, решая клиентские потребности, банк начинает создание собственной и независимой экосистемы. В конечном итоге банк получает существенные конкурентные преимущества, новые и современные клиентские приложения, возможность построения агентской схемы, подключения партнерских сервисов и создания маркетплейса, и множество другого бизнес- и ИТ-функционала, без которого в современном мире невозможно выстроить качественное и лояльное дистанционное обслуживание.

Наша команда создает системы ДБО и ЭДО уже более 15 лет, и мы знаем, как важно применить правильный подход к разработке решения и к проекту внедрения, для того чтобы избежать множества типовых проблем и ограничений. Платформа Salto и продукты, которые мы создаем на ее основе, спроектированы и созданы, опираясь на лучшие мировые практики, и ген «типовых проблем систем ДБО» в них отсутствует как таковой. Все указные выше проблемы решаются стандартными для нашей системы функциями и настройками, а множество других удобных и полезных инструментов упрощает и ускоряет разработку.

Мы с большим удовольствием поделимся с банками нашими опытом и решениями для построения современных систем дистанционного обслуживания.

В заключение позвольте сделать небольшой анонс нашей следующей публикации. В следующем номере журнала мы затронем достаточно объемную и сложную тему создания систем ДБО для крупных корпоративных клиентов класса «Централизованное казначейство». Наша компания обладает широким опытом создания таких систем, и нам есть чем поделиться с читателями журнала «ПЛАС». Обо всем этом и многом другом мы будем рассказывать на форуме iFin 2021.