Сегмент ДБО для корпоративных клиентов традиционно более консервативен и инертен к инновациям. Многочисленные отраслевые конференции сегментируют информационные потоки, жестко разделяя информационный контент; подразделения банков, курирующие корпоративный и розничный сегменты, как правило, изолированы от задач друг друга и почти никогда не смотрят на потребителя под одним углом. Но настолько ли кардинальны различия в целевой аудитории, инструментарии и подходах к взаимодействию? Нужно всегда помнить, что дистанционные продукты в корпоративном сегменте создаются для людей, а не для обезличенных компаний. Потребителя не интересуют внутренняя архитектура, технологический стек, лицензионная политика или ограничения регулятора. Для потребителя любое софтверное решение по самообслуживанию – это, прежде всего, end user interface. Любое ДБО должно строиться вокруг пользовательского опыта, и задача банков делать этот опыт проще, удобнее, функциональнее.
Долгие годы основным потребителем интернет-банка для юридического лица был сотрудник финансовой службы или бухгалтер. Не самый требовательный потребитель, не так ли? «В довесок» к неприхотливости этой части потребителей можно добавить и неизбежность использования сколь угодно неудобного ДБО по причине использования бизнесом, например, кредитного продукта в конкретном банке.
Вплоть до 2014 г. рынок этих программных продуктов как будто замер на месте: и без того небольшой по размеру, он был поделен между 4–5 всем известными вендорами, которые не предлагали ничего существенно отличающегося друг от друга с точки зрения пользовательского опыта. Данный сегмент отраслевых программных решений как будто пропустил случившуюся вокруг рынка интернет-технологий цифровую революцию, или, как ее еще называют, диджитализацию, со всеми вытекающими best practice из рынка цифровой коммерции и digital-маркетинга.
Какой пользовательский опыт в части корпоративных ДБО предлагают нам многие банки даже сегодня?
1. Установка и настройка рабочего места часто похожи на увлекательный IT-квест, для прохождения которого требуется или невероятное терпение, или помощь айтишника.
2. Мы все еще сталкиваемся с ограничениями на работу с интернет-банком в популярных браузерах и различных операционных системах.
3. Прорвавшись сквозь всевозможные неудобства и ограничения, мы попадаем в достаточно изолированную узкофункциональную среду, в которой часто ничего кроме базовой транзакционной функциональности сделать нельзя.
Только задумайтесь: информационная система, которой является в банке ДБО, достоверно идентифицирующая клиента, знающая его финансовое состояние, в 99% случаев абсолютно не приспособлена ни для комплексного обслуживания этого самого клиента, ни для роли удаленного офиса продаж банка.
Большая часть всех этих проблем давно уже решаема, и банки, сделавшие ставку на digital-канал, ушли в отрыв от менее прогрессивных коллег: рост базы «Точки», Модульбанка, «Тинькофф Бизнеса» тому яркое подтверждение.
Причин, объясняющих текущее состояние дел в корпоративном сегменте, достаточно много. Это и более строгое регулирование, и невозможность банка самостоятельно и своевременно развивать эти самые программные продукты под свои маркетинговые и бизнес-запросы, но прежде всего это другая специализация традиционных вендоров ДБО.
Для того чтобы на качественно ином уровне решить данную задачу, нужен совершенно другой тип компетенций в разработке цифровых систем, который исторически сформировался в среде разработки SaaS-сервисов и e-commerce-решений.
Успешные SaaS-сервисы и e-commerce-решения в своей ДНК бережно хранят миссию по улучшению оцифрованных пользовательских метрик. Digital-аналитика – основной источник принятия решений о развитии продуктовой среды взаимодействия с клиентом. Это сервисы для конечных потребителей, а не их представителей, которые никуда не денутся, как бы ни был неудобен интерфейс.
Прорыв и изменение парадигмы в обновленном взгляде на ДБО для юридических лиц стали формировать банки-новаторы, ориентированные прежде всего на предпринимателей. Эти банки вернули в среду ДБО тех, кто требователен к удобству, и тех, кто может принять решение о приобретении дополнительных услуг внутри этого целевого канала коммуникации.
Эти банки своими успешными примерами задали первый существенный тренд на определение места традиционного ДБО в IT-ландшафте банка: это разделение бэкэнда ДБО и создание независимого фронтального слоя продуктовой дистрибуции, в котором реализуются цифровые механики взаимодействия с конечным потребителем.
Тренд № 1 – разделение классического ДБО на независимый фронт и бэк
При формировании фронтальных платформ ДБО на первый план выходят не только UX-/UI-экспертиза в финансовых сервисах, но и e-commerce-экспертиза и неразрывно связанная с ней экспертиза в digital-маркетинге.
Как часто вы замеряли конверсии в своем интернет-банке? В современных фронтальных средах ДБО это неотъемлемая метрика для продуктового аналитика. Конечная реализация фронтального слоя дистрибуции в каждом конкретном банке – это воплощение принятой в банке digital-стратегии, наложенной на профиль абонентской базы: этот профиль определяет прежде всего набор востребованных нетранзакционных сервисов.
Возможность «разорвать оковы» стандартного дистрибутива ДБО на данный момент достигается двумя способами:
1) заменой старого поставщика ДБО на нового вендора, предоставляющего хорошо документированный и функциональный API для создания внешних фронтальных сред;
2) самостоятельной реализацией middle-слоя к старому решению ДБО, если лицензионная политика взаимодействия с вендором это позволяет.
Оба этих подхода имеют право на жизнь. Второй подход часто применим при большой лицензионной базе, и один из дополнительных плюсов — не нужно переобучать внутренний персонал. При кардинальной замене всего внешнего слоя взаимодействия с потребителем бэк-офисные интерфейсы, криптопрофили и ранее выданные токены не меняются.
Что это дает?
Пройдя путь функционального разделения ДБО на бэкэнд и фронтальную среду (рис. 1), банк открывает перед собой широчайшие возможности развития фронтальной среды под задачи маркетинга и бизнеса.
Рисунок 1
Разделение ДБО на бэкэнд и фронтальную среду
Фронтальный слой дистрибуции может быть сколь угодно глубоко и часто изменяем в отрыве от поставщика лицензий ДБО. Банку становятся доступны любые возможности по брендированию и проектированию удобных UI/UX-сценариев в интерфейсе и расширению их функциональности.
Привычная транзакционная составляющая ДБО может быть расширена до элементов продуктовой автоматизации по подключению новых услуг и продуктов банка и его партнеров. Причем речь идет не просто о классической лидогенерации из ДБО (заявке на новый тип продукта). Речь идет о встроенном в зону ДБО бизнес-процессе по предоставлению клиенту этой новой услуги: от анкеты/соглашения до юридически значимого электронного документооборота с использованием тех же самых криптосредств идентификации — без бумажек, без посещения операционного офиса.
Получив независимую фронтальную среду, банки в развитии своих ДБО-сервисов могут шагнуть навстречу следующему технологическому тренду – объединению коммуникационных сред и расширению продуктовой матрицы.
Тренд № 2 – объединение коммуникационных сред и расширение продуктовой матрицы
Сегодня на финансовых конференциях очень популярна тема маркетплейсов, кросс-продаж нефинансовых сервисов, расширения продуктовой линейки за счет услуг и продуктов, дополняющих РКО.
Однако перед тем как встать на путь кросс-продаж, задача банка во фронтальных средах ДБО – научиться интерфейсно объединять зону маркетинга продукта, среду управления подключенным продуктом и среду его продажи и подключения.
При таком подходе стираются границы между привычными, но, как правило, изолированными друг от друга информационными средами: сайт банка, веб-сервисы, портальные витрины, интернет-банк, мобильные приложения – все это единая коммуникационная среда (рис. 2), имеющая только два состояния (для авторизованного и неавторизованного пользователя).
Рисунок 2
Единая коммуникационная среда банка
А API-интегрированные сервисы в этой среде дают возможность клиенту получать любую услугу в несколько кликов: он не озадачен договорными отношениями с новыми поставщиками, контролем оплат, регистрациями – он просто подключает услугу, а банк списывает за нее деньги.Базовые вещи, с которых стоит начать, – это разработка и применение единой генетики интерфейса взаимодействия для разных коммуникационных сред. Единый стилевой лейаут, даже до этапа технологических интеграций, даст ощущение целостной информационной среды, а интеграция даст бесшовные сценарии перемещения потребителя из среды в среду, логично завершая цикл маркетинга покупкой.
Тренд № 3 – мультиформатность и мобильность
Несмотря на впечатляющие показатели роста мобильного банкинга в розничном сегменте, мобильный интернет-банкинг для юридических лиц все еще слабо развит. Накладывает отпечаток и то, что пользователь – это все еще бухгалтер, для которого достаточно браузерной среды, и более строгие требования к криптографии. У многих банков до сих пор нет мобильного интернет-банкинга для корпоративных клиентов, а у тех, где он есть, в большинстве своем превалирует исключительно просмотровый функционал.
Как и в случае с первым описанным трендом, траекторию изменений в корпоративном мобильном банкинге задали банки, ориентированные на предпринимателей, для которых полнофункциональное мобильное решение по управлению финансами так же привычно с точки зрения пользовательского сценария, как и управление персональными финансами в мобильном банкинге для физических лиц.
И тут стоит отметить успехи команды «Точки», чье мобильное решение уже нашло международное признание в премии SME AppsBank Awards, заняв третье место.
Мобильная среда не является заменой традиционному браузерному интернет-банку: при правильном подходе она должна позволять совершать все типы наиболее востребованных операций.
Если ваш банк только стоит перед задачей внедрения корпоративного мобильного интернет-банка, мы бы рекомендовали итеративный подход.
При построении архитектуры взаимодействия информационных систем наиболее правильным является использование общего слоя API для всех фронтальных решений: и для браузерного интернет-банка, и для мобильных приложений, и для b2b-платформ агентского класса.
Таким образом, приступать к внедрению функциональной мобильной платформы стоит как минимум после обкатки сценариев взаимодействия с потребителями в адаптивной браузерной среде и проверки функциональной достаточности API на наличие нужных методов и продуктов.
Современный браузерный интернет-банк должен быть адаптивен ко всем типам носителей: от широких мониторов до экранов смартфонов. На адаптивном интернет-банке можно отладить и проверить сценарии взаимодействия с мобильным трафиком, прежде чем приступать к внедрению полноценных мобильных приложений (рис. 3).
Рисунок 3
Этапы внедрения мобильных приложений
Если говорить о рекомендуемой последовательности внедрения, то мы бы ее описали так:
1) реализация удобного адаптивного интерфейса для браузерного интернет-банка (это можно делать даже в гайдлайнах iOS и Android отдельно);
2) внедрение гибридного приложения — оболочка с наиболее востребованными функциями классического приложения и коммуникационными механиками (touch ID, push-нотификации и т.д.) и встроенная в оболочку браузерная часть адаптивного интернет-банка;
3) полноценное мобильное приложение на кроссплатформенных или нативных технологиях.
Второй этап рекомендуется для быстрой проверки гипотез и снятия пользовательского фидбэка о функциональной достаточности.
Существует заблуждение, что развитие функционального мобильного банкинга под каждую мобильную платформу — это очень ресурсоемкий процесс. При нативной разработке это действительно так. Но сегодня существуют технологии одновременного развития как браузерных, так и мобильных сред с использованием общей кодовой базы, что существенно снижает ресурсоемкость и time to market функциональных компонентов безотносительно к типам носителей и операционным системам.
Кинетика при использовании таких технологий будет немного отличаться от нативной, но это компенсируется экономическим эффектом при поддержке и развитии всех систем сразу, ведь далеко не каждый банк может себе позволить развивать единовременно три различные компонентные базы интернет-банков по отдельности, поддерживая их функциональное единообразие.
Тренд № 4 – экосистемный подход, открытая архитектура, API для корпоративных и внешних информационных систем
Решив проблему удобства взаимодействия на пользовательском уровне, современное корпоративное ДБО становится всего лишь частью большого экосистемного подхода и в вопросах автоматизации бизнеса.
При таком подходе ДБО становится не только транзакционным инструментом, но и незаменимым поставщиком и реципиентом данных для автоматизации бизнеса: такое ДБО должно иметь «на борту» автоматические инструменты интеграции с популярными CRM-платформами, учетными и складскими системами, биллингами, биометрическими платформами, ритейл-системами и иметь открытый API для корпоративных IT-систем.
Немаловажно отметить, что потенциал ДБО с открытой архитектурой взаимодействия со сторонними сервисами имеет возможность влиять на автоматизацию и самого банка.
Простейший пример при операционном обслуживании: биометрическая идентификация и автоматизированная процедура поиска карточки клиента для операциониста.
Итоги
Современная дистанционная среда обслуживания строится на экосистемном подходе, где стираются границы изолированных ранее друг от друга информационных систем и используются всевозможные форм-факторы с сохранением функциональных возможностей.
Воплощение такого подхода в жизнь объединяет работу многих традиционных банковских подразделений. Необходима их слаженная работа в формате единого «проектного офиса», а роль традиционного поставщика ДБО все больше и больше будет сводиться к «кубику» в схеме бэкэнд-архитектуры. При этом банкам важно менять и подходы к управлению реализацией и бюджетированию таких проектов.
Банки – это консервативные структуры, и многие до сих пор не умеют работать по Agile с внешними подрядчиками и поставщиками, а еще меньшее количество умеют применять подходы Agile в финансировании.
Однако только гибкое управление требованиями и гибкие методологии реализации (рис. 4) позволяют выводить на рынок успешные продуктовые кейсы, не уходя в проектные «долгострои».
Рисунок 4
Гибкая методология реализации
Пока банки, выделившие задачи по трансформации ДБО в отдельные структуры digital-банкинга и inhouse-лаборатории, демонстрируют более высокий рост. Возможны ли сейчас успешные кейсы в банках с традиционной оргструктурой и традиционными подходами к проектной деятельности – вопрос открытый.
