Описанный в статье подход к сегментированию цифровых сервисов при наличии соответствующей программной архитектуры позволит банку шаг за шагом с разными уровнями автоматизации оцифровать наиболее критичные продукты и процессы, делая их частью своей дистанционной экосистемы обслуживания.
Классическая транзакционная функциональность дистанционного обслуживания уже сформировала отраслевые стандарты цифрового daily-банкинга. Речь идет о полноценной платежной функциональности вне зависимости от форм-фактора дистанционного канала — работе со всеми типами платежных операций, UX-/UI-механиках, упрощающих проведение платежей:
— умной шаблонизации на основе частотных платежей в историях операций;
— статистике, инструментах автозаполнения и рекомендаций;
— интегрированных сторонних сервисах для прескоринга контрагентов;
— расшифровке QR-кодов в данные платежных поручений;
— распознавании графического формата в инвойс и т.д.
Дальнейший «поход в цифру» начал затрагивать традиционно офлайновые бизнес-процессы: от онбординга новых клиентов до полноценного цифрового управления жизненным циклом финансового продукта внутри авторизованного ДБО-канала.
Онбординг клиента. Проблемы управления жизненным циклом продукта
Онбординг клиента — это процедура от лидогенерации до предоставления услуги. В зависимости от типа продукта, законодательных ограничений и бизнес-процесса онбординг может быть:
— исключительно офлайновым с момента лидогенерации (получили заявку — пригласили в операционный офис);
— полуцифровым — когда основная часть взаимодействия происходит через цифровой канал, но какая-то из операций все еще требует офлайн-коммуникации в операционном офисе или с участием курьера (пример: открытие расчетного счета);
— полностью цифровым — когда механика взаимодействия замкнута исключительно на digital-интерфейс, который работает по статусной модели обработки заявки на продукт, валидируя информацию от конечного клиента с помощью НЭП или КЭП (пример: получение цифровой банковской гарантии).
Хорошими примерами управления жизненным циклом продукта могут служить ипотечный кредит через ДБО или страховые продукты — те продукты, которые завязаны на ДБО-канал, но работа с которыми длительна во времени.
Заявка на ипотеку может быть полуцифровой и предусматривать офлайновый контакт исключительно в момент подписания ипотечного договора, но как только кредит выдан посредством ДБО, помимо операций погашения конечному потребителю крайне важна нетранзакционная функциональность сопровождения ипотечного кредита:
1) запросы справок для разных типов налоговых вычетов, информации об объеме уплаченных процентов, остатке ссуды и т.д.;
2) заявления на досрочное погашение с пересчетом последующего графика платежей;
3) заявления на рефинансирование и замену ставки в рамках действующих в банке программ.
Аналогичный пример — цифровые услуги по страхованию: внесение изменений в цифровые полисы ОСАГО/каско, прекращение действия договора.
Однако в попытке создания полноценных цифровых сервисов банки неизбежно сталкиваются с ограничениями legacy-систем, юридическими рисками и потребностью трансформации целевых процессов в операционных отделениях и бэк-офисе.
Пример: любая кредитная заявка в крупном универсальном банке или анкета на дистанционное открытие расчетного счета. Процесс формирования и набор информации, настроенные в АБС, не соответствуют набору упрощенных данных для цифрового сервиса. АБС не умеет в режиме реального времени обрабатывать анкетные данные и давать ответ по статусной модели, или банк не может обеспечить предоставление услуги с одинаковым набором запрашиваемых данных в операционном офисе и через цифровой канал.
Отсюда появляются тяжеловесные анкеты и заявочная функциональность без real-time режима, потому что между фронтальным сервисом и целевой системой может быть абсолютно офлайновый процесс, завязанный на какой-нибудь Lotus и ручной перенос данных в АБС или CRM сотрудником контакт-центра.
«Микс» из этих ограничений предъявляет серьезные требования как к используемым программным платформам, так и к архитектурной концепции реализации новых цифровых продуктов.
Какие особые требования появляются при построении цифрового офиса?
Речь идет о сквозной перестройке процесса предоставления услуги — от фронт-офиса до мидл-офиса и core-систем. Каждый слой каскадно затрагивает методы API-интеграции, требуя расширения моделей данных и доработок под проектируемый бизнес-процесс работы с продуктом. Учитывая, что большинство таких сервисов делаются не на green-field ландшафте, требуется принимать во внимание сохранение целостности данных по ранее открытым продуктам и необходимость доработки как клиентских, так и фронт-офисных систем.
Очевидно, что сегодня мы являемся свидетелями отмирания классической модели дистрибуции ДБО, поскольку ни один типизированный программный продукт больше не способен в рамках своего контура решать появляющиеся цифровые задачи «из коробки».
Сейчас уже ярко выражен тренд, когда дистанционная экосистема не строится на одном ДБО-продукте, как было еще 3–5 лет назад. Банки все чаще ищут не «коробку» от вендора, а программный фреймворк с возможностью самостоятельной разработки с обучением своих специалистов. Почти все крупные банки пошли в разработку собственных бэкэндов, отдельных микросервисов и отдельных фронтальных порталов или нашли вендоров, которые согласились продать исходные коды платформ для полноценной инхаус-разработки (кейс Дело Банка: инхаус построен на изначально вендорной платформе, но это тоже не «коробка», а набор сервисов с открытым исходным кодом).
Архитектура, когда поверх core-систем была бы только шина данных как поставщик API для фронт-офиса, без традиционной «коробки» ДБО практически не встречалась. В настоящее время, даже если в архитектуре продолжает оставаться компонент от «коробки», он, как правило, начинает отвечать за узкую функциональность, а остальное «наращивается» поверх и рядом. Примером может служить сервисная архитектура, появляющаяся в проекте нового корпоративного онлайн-банка в ВТБ (около 80 бэкэнд-микросервисов) или БКС Банке (микс технологий микросервисов, .NET Core и Java).
Основные потребители инструментов цифровой трансформации — это крупные универсальные банки, иногда и со своими инхаус-лабораториями.
И чем больше вариаций бэкэнд-ландшафтов в таких банках, тем важнее роль наличия в архитектуре дистанционного канала, консолидирующего все типы данных для независимого фронта, открытого кластеризированного на отдельные сервисы бэкэнда и мидл-слоя, каждый из которых должен давать инструментарий разработки и развития, в том числе и для инхаус-лабораторий банков.
Если логика разделения монолитного ДБО на две части — архитектурный API-зависимый фронт и отдельный бэк — была в первую очередь продиктована задачами улучшения UX-/UI-механик daily-банкинга имеющихся решений ДБО, то дальнейшая логика пересмотра архитектуры ДБО в сторону кластеризированного сервисного бэкэнда продиктована потребностью развивать рядом и внутри ДБО дополнительные нетранзакционные сервисы, где источниками данных для фронта уже являются не только бэкэнд ДБО, но и другие целевые системы: АБС, CRM, кредитный конвейер и т.д.
Реализация цифрового продукта для конечного клиента в любом случае требует изменения core-систем, но подход с децентрализацией бэкэнда позволяет избежать дублирования доработок в мидл-слое/ядре ДБО, собирая данные в общий бесшовный фронт.
Как происходит сборка в бесшовный фронт?
Бесшовный фронт собирается с помощью Identity Server. Примером может служить следующий кейс: личный кабинет и интернет-банк, у которых разные бэкэнды, но общая авторизационная пара. Для клиента все сводится в единую интерфейсную механику (рис. 3).
На практике децентрализация бэкэнда ДБО позволяет использовать даже разный технологический стек в сервисах. Мы уже видим, как могут соседствовать сервисы на .NET core и Java в рамках общей цифровой экосистемы банка, объединенной единым фронтом.
Бэк-сервисы все больше становятся исключительно интеграционным транспортом, требующим конфигураций и доработок под специфику продуктового процесса конкретного банка. Будущее за поставщиками, которые обеспечат открытость, отчуждаемость и дорабатываемость таких компонентов и сервисов без своего участия в качестве вендоров.
Принципиальное отличие будущей архитектуры от привычных инструментов интеграции, таких как IBM WebSphere, в том, что это шина, которая обеспечивает целостность и связанность данных и процесс, а не продуктовые свойства. Речь о дискретных микросервисах для продуктов, выводимых в интерфейс (зарплатный проект, валютный контроль, конверсионные операции и т.д.). Но даже выбрав верную целевую архитектуру дистанционного канала, банку неизбежно придется балансировать между реализацией digital и псевдо-digital сервисов.
Что такое псевдо-digital сервисы?
Псевдо-digital сервисы — это когда целевой процесс для клиента заканчивается заявкой без интегрированного ответа систем. По факту заявка может превратиться даже в аттач для почтовой системы и далее в ручном режиме обрабатываться и заноситься в требуемые информационные системы.
Под псевдо-digital сервисами мы подразумеваем сервисы, которые без обеспечения физического онлайн-взаимодействия в бизнес-процессе предоставления услуги через пользовательский интерфейс покрывают пользовательский сценарий взаимодействия исключительно в цифровом канале.
Реализация псевдо-digital сервисов прекрасно подходит для MVP — вывода на рынок цифрового продукта без существенных доработок на стороне core-систем. Большинство таких сервисов несут для клиента заявочные функции, для core-систем — функции распоряжений в свободной форме. Пример: обычная заявка на подключение торгового эквайринга без оплаты и регистрации аппарата для отражения операций в ДБО. Асинхронная обработка документа создает для клиента полноценную цифровую иллюзию без перевода взаимодействия в другой канал коммуникации, но уровень автоматизации для таких сервисов внутри банка крайне низок.
Три способа реализации цифрового банковского офиса
Основой для сервисов цифрового банковского офиса служат процессы или онбординга нового продукта, или сопровождения по его жизненному циклу: управление распоряжениями, связанный документооборот, обработка исключений и сценариев прекращения использования услуги. Исходя из этой специфики, просматривается три основных способа реализации цифрового банковского офиса «рядом» с daily-банкингом:
1) stand-alone сервисы по отношению к ДБО;
2) сервисы, «стоящие рядом» с ДБО и использующие с ним единую авторизационную сессию;
3) полноценно интегрированные в ДБО решения.
Первый тип сервисов самый простой — он прекрасно подходит для построения цифрового онбординга: открытие расчетного счета, получение банковской гарантии без открытия расчетного счета, заявочные сервисы, бизнес-цикл которых замыкается, например, на скоринговое решение, и т.п.
Второй тип — это продукты, работа с которыми требует продолженного взаимодействия в ДБО. Для таких сервисов желательно обеспечить интерфейсную идентичность, бесшовный переход между сервисом и ДБО, использование единых авторизационных данных.
Третий тип подразумевает полноценный информационный обмен между сервисами, объединение интерфейсных механик, доступ к об-щим данным из бэкэнда цифрового сервиса и бэкэнда ДБО.
Для любого типа реализации сервисов цифрового офиса важно интегрированное взаимодействие с используемым в ДБО поставщиком ЭЦП (НЭП или КЭП).
Каждый последующий тип является по сути функциональным расширением предыдущего, создавая больше целостных интерфейсных механик для конечного потребителя.
Источник: http://futurebanking.ru/reglamentbank/article/5740?access_key=3fGVYN
