Из оффлайна в онлайн: 6 советов, как настроить диджитал-процессы в экосистеме европейского банка

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

В 2018 году к нам обратился европейский TBI Bank. Он только начинал развивать диджитал-инфраструктуру и хотел полностью трансформировать процессы, чтобы клиент мог совершить любую операцию, не посещая отделение банка. За 1 год заказчик хотел перевести 30% всех клиентов в онлайн-обслуживание.

Команда KODE должна была разработать банковское мобильное приложение для обслуживания кредитов. В результате мы достигли цель через 1,5 года, при этом год нам понадобился на то, чтобы подготовить инфраструктуру заказчика к цифровизации.

На основе своего опыта мы выделили несколько ключевых моментов, предугадав которые, можно было выжать ещё больше из «железного треугольника».

Итак, что нужно делать, когда перед вами стоит задача перевести в онлайн банковские процессы или любую другую организацию с хитросплетёнными сетями взаимодействий:

1. Настроить диджитал-процессы в экосистеме банка для интеграции с новой инфраструктурой

Важно определить, насколько хорошо подготовлены digital-процессы в экосистеме банка. Часто даже самые большие и серьёзные структуры, которые хотят реализовать банковский функционал, могут оказаться не готовы к его реализации на онлайн-площадке.

Нужно отнестись к этому максимально серьёзно. Как оказалось, это ключевой фактор успеха. Мы, например, изначально воспринимали проект только как разработку мобильного приложения, но в результате потратили много времени на подготовку инфраструктуры банка.

На что обратить внимание, оценивая готовность инфраструктуры заказчика к цифровизации?

  • Готовность методов бэка. Они должны быть протестированы, задокументированы и работать корректно.
  • Наличие описанных технических и бизнес-требований. Круто, если в банке работает большая команда бизнес-аналитиков, которая составляет корректные технические и бизнес-требования. Но мало написать требования: их нужно постоянно поддерживать в актуальном состоянии, потому что роадмап в финтехе меняется на 50% за 3 месяца. Требования должны меняться, когда меняются приоритеты и цели банка, набор функционала и взаимосвязи между фичами.
  • Data driven подход. Проводит ли банк собственные исследования и делает ли выводы на основе данных. Это лучше, чем ориентироваться на тенденции рынка без анализа.

Что делать, если заказчик не готов, а команды аналитиков у него нет?

Вариантов может быть много. KODE выбрала глубокую интеграцию в процессы банка — на этом этапе нам в первую очередь помогли доверие заказчика и его открытый подход к сотрудничеству. Затем помогли банку наладить процессы и начали цифровизацию.

Сначала команда получила технические ограничения от заказчика. Вот несколько из них:

  • Загруженность сотрудников. От этого зависело, сколько человек со стороны банка будет участвовать в процессе цифровизации, а сколько нужно привлечь с нашей стороны.
  • Готовность программных модулей. Наш скоуп работ определялся в зависимости от степени готовности методов бэка. Например, готов ли на стороне банка интерфейс по обработке платежей по кредиту или модуль по генерации электронных контрактов для их подписания.
  • Бизнес-приоритеты банка. Высокий приоритет выставлялся тому функционалу, который был одновременно ориентирован на клиентов и бизнес: например, возможность уменьшить размер ежемесячных выплат по кредиту.

После этого начали интеграцию с помощью требований и наладили культуру работы с данными.

К нам присоединилось несколько бэкенд-разработчиков со стороны заказчика, которые были включены в проекты банка. Синхронизация с нашей командой сначала выглядела как челлендж и отнимала много времени. Мы решили объединить усилия: оптимизировали процесс настройки бэка для интеграции с приложением, стали оценивать сроки выполнения задач на стороне банка и разрабатывать свою часть функционала к этому же времени.

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

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

Вместе с заказчиком мы начали работать с первичными данными, внедрили A/B-тестирование и аналитику в маркетинг. Это дало быстрый результат и доказало необходимость налаживать культуру работы с данными. Решения стали приниматься на основе data driven подхода, банк смог лучше отслеживать KPI приложения после выпуска новой фичи и повысить качество прогнозов. В результате TBI Bank вырастил свою инхаус-команду аналитиков, которая помогает делать продукт лучше.

Для нас это вылилось в большое число итераций при разработке фичей. Часто приходилось перерабатывать целые сценарии из-за того, что инфраструктура на стороне банка не позволяла получить доступ к тем или иным данным. С развитием инфраструктуры пользовательские сценарии удалось сократить и упростить.

Александр Иванова
Android-разработчик

Сейчас KODE продолжает писать требования для всех экосистем, с которыми взаимодействует мобильное приложение банка, и делиться опытом с их специалистами: консультировать системных аналитиков, DevOps, QA и специалистов по автоматизации.

2. Придерживаться принципов аджайл

Сформированная система коммуникации позволяет постоянно находиться в одном информационном поле с заказчиком и выстраивать прозрачные процессы по задачам.

Что нам помогает:

  • Ежедневно созваниваемся для синхронизации приоритетов.
  • Общаемся с заказчиком дважды в неделю.
  • На дейли всегда присутствует PM со стороны заказчика.
  • Создали общую конфу для обмена знаниями.
  • Проводим баг-ревью 1 раз в неделю.
  • Используем 2 отдельные джиры. Это позволяет обеим сторонам не выходить за рамки внутренних бизнес-процессов.

3. Ломать роадмап, когда нужно

Разработка велась 2-недельными стримами, а согласованный роадмап должен был нас привести к финалу только через год.

К моменту завершения второго полугодичного периода результат работы сильно отличался от запланированного. Менялись потребности банка — менялись наши задачи, а вместе с этим корректировался роадмап.

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

Сейчас наши этапы длятся 2 недели. Это оптимальный срок, который стал удобен нам и заказчику. Кроме того, дополнительно вернули полугодовые роадмапы, потому что банку было важно сохранить прогнозируемость на долгосрочный период.

4. Не жертвовать улучшением существующего функционала во имя новых фич

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

TBI Bank следует трендам и активно работает над тем, чтобы превратить кредитный банк в дейли-банк. Работа ведётся одновременно по двум направлениям: улучшаем существующий кредитный функционал приложения и планово внедряем новые функциональности в продукт. В нашем случае всё работает в режиме 50 на 50.

Выглядит эта красота примерно так:


Работа двух параллельных стримов

5. Активно интегрироваться с вендорами

Для выхода на рынок компании могут выбрать одну из трёх стратегий:

  • Разработка всего функционала с нуля.
  • Использование готовых коробочных решений, которые ограничивают бизнес по функционалу.
  • Применение гибридного подхода: использование готовых решений и кастомных разработок на базе своей инфраструктуры, которые отвечают уникальным бизнесовым требованиям конкретной компании.

KODE и TBI Bank придерживаются последней стратегии, так как это позволяет сократить сроки реализации и предоставить качественный продукт.

Переводя процессы из офлайна в онлайн, TBI Bank выбрал стратегию ведущих банков Европы: максимальное сокращение расходов и времени на инфраструктуру. Это резонно, так как на некоторый функционал бэка можно потратить много времени. Выгоднее найти вендора, который предоставит уже готовое решение.

Использование вендоров помогает расширить круг пользователей приложения за счёт предоставления большого количества функционала в короткий срок. И, в конечном итоге, превратить кредитный банк в дейли-банк. Уже сейчас TBI Bank удалось реализовать 50% от объема всей необходимой инфраструктуры.

Мы, как разработчики, проявляем гибкость: одинаково быстро готовы интегрироваться с готовыми системами банка и с новыми вендорами.


Упрощённая схема вендоров

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

По той же причине пришлось самостоятельно реализовывать аналог, который у нас называется системой быстрых платежей. Европейское законодательство в банковской сфере отличается от российского, и в ЕС возможны только переводы по iban (со счёта на счёт). Команда KODE разрабатывает удобный интерфейс, который отвечает требованиям законодательства, но для пользователей выглядит как простой перевод по номеру телефона. В этом случае нельзя подключить вендора, потому что придётся отдать конфиденциальные данные пользователей: номера телефонов и счетов.

Банк отбирает вендоров по следующим критериям:

  • Технические возможности. Среди них — масштабируемость, доступность и возможность интеграции.
  • Сложность архитектуры. Многопользовательская поддержка, возможность повторного использования системы.
  • Опыт вендора. Количество реализаций, роадмап развития и система поддержки.
  • Соответствие требованиям безопасности. Сертификация eIDAS, соответствие GDPR и PSD2 (SCA), особые и общие требования безопасности (включая ISO 27001).
  • Функциональное покрытие. Аутентификация клиента по запросу, поддержка нескольких языков (болгарский, румынский, греческий, английский, польский), механизмы восстановления и сброса пароля.

Вот несколько сервисов, которые нам удалось успешно интегрировать:

  • Вендор, который выпускает карты и приложения для интеграции с ним. Интеграция проходила бесшовно — простым API на сетевом уровне. Вместо этого TBI Bank мог потратить год, чтобы самостоятельно разработать такую штуку в банке.
  • Вендор для системы приёма платежей. Провели интеграцию и также добавили сохранение карт в системе. Фича была реализована за 3 недели. Изначально подключали вендора для оплаты кредитов, сейчас он также используется и для пополнения карты.

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

Вот кейс, когда мы самостоятельно создали фичу, а чуть позже сделали выбор в пользу вендора, потому что это было выгоднее для продукта.

Создали систему самоидентификации пользователя по ID – без видеозвонка для подтверждения личности

В ЕС существует требование, согласно которому пользователь при входе в банковское приложение должен самоидентифицироваться. Для этого ему нужно отправить свою фотографию и 2 разворота паспорта.

Сначала команда встроила в приложение систему, которая получает и проверяет фотографии по метаданным: дате создания и девайсу, на котором они были созданы. Только после оценки актуальности снимков система отправляла их в банк для распознавания. Фотографии с низким баллов валидации сразу отсекались.

Кроме этого, нам нужно было донести, что сфотографировать свой паспорт при регистрации и отправить данные — это безопасно. Болгарская аудитория не достаточно доверяет digital-решениям, чтобы пользоваться мобильным приложением: она не готова передавать личные данные по цифровым каналам.


Система самоидентификации пользователя по ID

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

6. Использовать чаты как ещё один канал онлайн-продаж

Ранее в TBI Bank вся поддержка клиентов велась через отзывы и колл-центр. Потом добавили форму обратной связи, но система по-прежнему оставалась односторонней.

Изначально чат запускался как пилотный проект, чтобы понять, можно ли его масштабировать. Пилот был на отдельном стриме и никак не влиял на основной. Для реализации фичи решили тоже использовать вендор — Zendesk. Она вовремя вышла в релиз и показала хорошие результаты.

С появлением чатов вопросы пользователей стали решаться быстрее, а банк получил дополнительный канал продаж. TBI Bank получил конкурентное преимущество на болгарском рынке и стал единственным банком, предоставляющим онлайн-поддержку клиентов 24/7.

Отзывы заказчика

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

Райчев Здравко
Управляющий директор TBI Bank

KODE показала себя как надёжный партнёр, который может всегда прийти на помощь в любой ситуации и в кратчайшие сроки предоставить уникальную экспертизу в разработке. KODE помогает превращать в реальность нашу phygital-стратегию и строить новую эру в мире банковского обслуживания.

Александр Кислашко
CIO, mobile TBI Bank

Добавить комментарий

%d такие блоггеры, как: