Почему мы не строим экосистему: что делать, если ты не госбанк
Идея построения банковских экосистем и маркетплейсов появилась в поисках роста ARPU (англ. Average revenue per user, средняя выручка на одного пользователя), удержания клиентской базы, привлечения новых клиентов за счет бесшовного предоставления финансовых и нефинансовых сервисов. Даст ли экосистема ожидаемый результат? Однозначного ответа на этот вопрос нет. Зато точно можно сказать, что построение экосистемы требует огромных инвестиций и времени. Это могут себе позволить крупные госкорпорации или госбанки. Что делать, если ты не госбанк?
Гигантские затраты и сомнительная прибыль
Банковские экосистемы обычно предлагают клиенту широкий список услуг: от страхования и услуг мобильного оператора до телемедицины и билетов на мероприятия. В секторе B2B добавляется регистрация бизнеса, онлайн-кассы, бухгалтерия, рекламное продвижение. Чтобы эта система хорошо работала и приносила реальную прибыль, в первую очередь нужен трафик. Здесь отмечу, что даже крупнейшие банки страны со своим трафиком не входят и в двадцатку лидеров.
Наряду с трафиком критична качественная реализация сценариев клиентского пути, требующая значительных компетенций и ресурсов. Помимо партнерства с провайдерами сервисов экосистемы необходимы вложения в качественный UX и технологическую интеграцию. Еще один критичный аспект – ключевой ценностью при построении экосистемы являются данные клиентской активности в сервисах. Нам нужна эффективная среда для управления данными, а значит – дополнительные крупные финансовые вложения.
Все это приводит к тому, что для создания правильно работающей экосреды требуются гигантские инвестиции. По оценке ЦБ банки уже вложили в непрофильные активы около 2,4 трлн. рублей. Такой путь доступен только самым крупным игрокам рынка, но даже в их случае мы не знаем, будет ли построение экосреды выгодно. Потребуется ещё много времени и средств, возможно, смена провайдеров, корректировки концепций, а в случае успеха им придется противостоять сильной конкуренции со стороны интернет-гигантов и мощных нишевых игроков.
При этом standalone качественный банковский сервис и удобный ежедневный доступ к финансам остается ценным и востребованным клиентами.
Через фьорды к звездам
Фокусировать свое внимание на качественных финансовых сервисах, эффективном управлении рисками и работе с клиентской базой, непрерывно улучшать и упрощать клиентский опыт — таким я вижу путь негосударственного банка. При этом ничто не мешает предоставлять партнерские сервисы «ближнего круга», тем самым обмениваясь трафиком и повышая клиентскую лояльность в околофинансовых сферах: страховании, инвестициях. Возможна также продажа партнерских сервисов в B2B и B2C с минимальной UX интеграцией. Кроме того, важно постоянно повышать эффективность процессов и технологий.
Оптимизации в IT нас научил скандинавский минимализм. Речь о том самом направлении дизайна, зародившемся в середине XX века. В то время Северная Европа еще не стала богатым регионом, но ее жителям хотелось пользоваться красивыми и удобными вещами. Так местные дизайнеры придумали подход, в основе которого лежат два принципа:
- Акцент на главной функции. Каждый предмет должен выполнять ту роль, ради которой он создавался и ради которой его покупают.
- Экономия на производстве. Ее можно достичь как за счет отказа от создания лишних функций, так и за счет переиспользования уже существующих ресурсов.
Например, клиенту нужно место, чтобы хранить книги. Для этой задачи дизайнер разработает простую полку, откуда легко достать любой предмет. Клиенту не нужен громоздкий шкаф с дверцами, которые нужно открывать и закрывать — это лишние действия. Саму полку можно изготовить из переработанной древесины, что позволит сэкономить на производстве.
Мы в банке «Санкт-Петербург» решили, что принципы скандинавского минимализма вполне применимы в IT. На их основе мы строим эффективный IT-ландшафт и IT-дизайн, принимаем архитектурные и управленческие решения. Мы считаем, что эти принципы позволят нам развить конкурентное преимущество на рынке с максимальной отдачей от вложенных ресурсов. Скандинавский подход помогает сэкономить на разработке и создавать сервисы, которые будут действительно удобны и полезны людям.
Вот несколько базовых принципов IT в стиле минимализма, которые мы для себя приняли и которым следуем:
выбирать решения на основании изучения клиентского опыта (да, это очевидно, но почему-то не всегда применяется)
не порождать новых элементов в ландшафте, убирать дублирующий функционал, понижать связанность систем и приложений
уменьшать комплексность ролей и процессов в IT dev и ops
системы, не влияющие на клиентов или доходы банка, – с нулевым аппетитом к кастомности
для критичных клиентских систем – собственная разработка или готовые сервисы (всё чаще – cloud)
сloud-native подход к разработке нового в целях готовности к очевидному следующему шагу на пути в повышении эффективности инвестиций в IT — поэтапному переходу в мультиоблачную инфраструктуру
минимум хайпового «космоса», фокус на работающих инструментах, удалении неработающих или сложных
Один из примеров работы по этим принципам – наш новый мобильный банк, который уже доступен в сторах. Приступая к его разработке, мы ставили перед собой всего две задачи:
1. Построить простой мобильный банк со всеми необходимыми финансовыми сервисами.
2. Предоставить клиенту возможность получать точные и своевременные предложения от банка.
Что мы сделали?
Команда разработала новое приложение на базе более чем 50 микросервисов, которые полностью готовы к размещению в облаках. Мы по максимуму использовали платформенный UI (iOS, Android), чтобы быть проще и ближе к шаблонам поведения пользователей. Интегрировали в приложение более десятка готовых сервисов от провайдеров-лидеров рынка: чат, антифрод, система мониторинга, QR и другие. Для качественного управления предложениями для клиентов разработали свой комплекс, который назвали Digital offering management system (DOMS), написали о нем подробнее здесь — набор сервисов, интегрированных в ландшафт банка (централизованную систему офферинга и систему управления данными) и размещенных в публичном облаке.
Несмотря на обилие микросервисов, новое мобильное приложение Банка «Санкт-Петербург» — не трендовый Superapp. Это классическое банковское приложение, не утяжеленное дополнительным функционалом. Мы полностью отвечаем скандинавской концепции — сохраняем простоту, которая зачастую необходима пользователям. Супераппы могут принести клиенту боль из-за обилия функций, в которых сложно разобраться, а еще иногда в таких приложениях попросту сложно что-то найти.
Мы считаем, что от банковского приложения клиенту в первую очередь нужен сам мобильный банк как инструмент управления финансами — Daily banking. При этом он должен быть доступным, простым и удобным. На этом мы и сосредоточились, убрав всё лишнее. Мы учли тот факт, что клиенты все меньше посещают отделения банка, и им нужен Digital office, чтобы совершать необходимые операции удаленно.
Технически, как я упомянул выше, мы перешли на архитектуру микросервисов. Таким образом был улучшен Time To Market, и с момента идеи до появления функционала у клиента проходит меньше времени. Вместе с этим, архитектура микросервисов — это лучшая практика бесперебойности. Если в работе какой-то отдельной функции возникают проблемы или требуется обновление одного из микросерсвисов, мы «закрываем отсек на ремонт», делая его недоступным для пользователя, а остальной функционал полноценно работает.
Я недавно подумал о тяжелых банковских приложениях и экосистемах. К ним отношусь скептически. Я считаю, что вы выбрали правильный путь.
Я уже писал в обсуждении экосистем другого банка, повторюсь и тут. Клиент чаще запоминает и транслирует другим негативный опыт. При этом какой-то косяк одного из сервисов, объединённых общим названием, в сознании увязывается с основным брендом. Условно, приехал хамоватый водитель, который всю дорогу нарушал ПДД, от БСПБ-такси, а у потребителя откладывается, что это банк плохой, раз "у него" такие водители. То есть поддержание системы требует повышенного внимания к качеству сервисов побочных брендов. Для потребителя это хорошо, но для банка лишняя непрофильная нагрузка.
А что касается "скандинавского минимализма", не указав самый известный из брендов, исповедующих это, — позабавило. Наверно, что-то из этого ещё можно взять. Я вот например в том шведском магазине обязательно беру фрикадельки и заглядываю в отдел уценённых товаров. Это непременный ритуал. Как перенести на банковское обслуживание? Помнится, Открытие экспериментировало, и открыло отделение, совмещённое с кофейней. Вот не знаю, сохранился такой формат у них или нет. Давно в кофейном офисе не был. А в том, где в основном обслуживаюсь, мне и так менеджер предлагал кофе, пока я не объяснил, почему не пью его. Но банк с фрикадельками это будет несомненно фишка. С отделом уценки ещё проще. Достаточно лишь переименовать раздел "Реализация залогового имущества" и вот оно! И для полноты картины можно продумать реализацию банковских продуктов в коробках, самовывозом.
И ещё один вопрос, который меня волнует уже очень давно. Почему? (2 картинки ниже)
По второму вопросу: наверное, потому что конкуренту очень понравился наш логотип :)
Аналогии очевидны 😊, однако мы не стремимся выстроить такую связь - Банк и известный бренд скандинавского дизайна. Сейчас мы говорим прежде всего о вдохновении и переиспользовании принципов простоты в комплексных IT-вопросах. В любом случае, спасибо за идею, мы обязательно подумаем в этом направлении 😊
Микросервисы или все же лоскутное одеяло? Насколько интеграции чувствительны к доработкам?
Отвечая на первый вопрос, хотелось бы отметить, что в нашем банке мы не гонимся за тотальным покрытием ландшафта микросервисами. Мы видим, что ценность от этого подхода есть прежде всего в областях, где есть высокая вероятность переиспользования (такие темы очевидны в авторизации и аутентификации, подписании документов, сервисах информирования, в платежах, клиентских данных, заявках на продукты и других), а также там, где необходимо быстрое масштабирование и где мы планируем или уже осуществляем работу в облачной инфраструктуре. При этом мы не торопимся переводить наши большие монолитные банковские системы (прежде всего это core-системы) на микросервисы, т.к. эффект тут не очевиден, и если будет интересно, можно будет этот вопрос раскрыть в отдельной более глубокой статье.
Ответ на второй вопрос очень простой – да, интеграции чувствительны к доработкам. Когда-то, уже наверно десятки лет назад, во времена, когда SOA был на таком же хайпе как и сейчас микросервисы, часто реализовывались такие подходы, при которых при разработке интеграции разработчики закладывали избыточный формат обмена, а интегрируемые системы сами решали, что им нужно использовать. У этого подхода есть и плюсы, но и минусов предостаточно – повышенный трафик, нагрузка на КСПД, замедления в формировании сообщения и последующем парсинге, более долгая разработка и др. Если же мы говорим о более простом подходе, подходе «минимализма» - то лишнего делать не следует, вместо этого лучше иметь возможность быстро вносить изменения в код и быстро ставить их в production.
Новое приложение выглядит минималистично и удобно, но есть все же пара недостатков: не узнать местонахождение офисов и банкоматов, не работает поиск, да и в целом, блок "еще" выглядит пустовато. Радует, что в чате отвечают и счета не блокируют)