Через тернии к Омни. Эпизод 4. Омниплатформа. Схема принципиальная, электрическая

Предлагаю поговорить об ИТ-архитектуре в контексте типовых стратегических целей цифровой трансформации:

• предоставление качественных цифровых сервисов;

• формирование лучшего клиентского опыта;

• обеспечение надежности систем.

Как ВТБ подошел к реализации омниканальной архитектуры? Она обеспечивает быстрый вывод продуктов и сервисов через разные каналы клиентам и поддерживает высокое качество обслуживания.

Для начала проанализируем ИТ-архитектуру в ВТБ 2019 года, которая, по нашей классификации, относится к поколению 4 — преимущественно трехзвенная архитектура, с элементами клиент-сервера.

Итак, что находилось на фронтальной линии, формирующей клиентский опыт?

• Мультиканальность — это, когда продукты живут по правилам канала, в который они выведены;

• Основу клиентского взаимодействия ВТБ составляли многочисленные приложения в каналах самообслуживания для одного сегмента клиентов, каждое из которых работало по своим правилам. А также фронтальные приложения для сотрудников, построенные на разных моделях обслуживания, архитектурах и технологиях;

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

Как были организованы архитектура АБС и процессинг?

ВТБ использовал несколько АБС, таких как БИСквит, ЦФТ, мБанк, ЦАБС, OGRESS, zFront, и две процессинговые системы — Way4 от ВТБ24 и Банка Москвы, что создавало сложности в управлении данными и операциями.

Где хранились данные? Данные хранились и обрабатывались в нескольких местах, включая наследие ВТБ24 и Банка Москвы, а также КИХ ВТБ, что усложняло их обработку и анализ.

Какой была продуктовая логика? Она была распределена по различным «местам»: фронтальные системы, сервисные и интеграционные слои, АБС и процессинг, что повышало сложность управления и замедляло вывод продуктов на рынок.

Какие архитектурные решения были использованы?

• Основные фронтальные системы самообслуживания использовали трехзвенную архитектуру (ВТБ Online и Business Online, БИФИТ, BSS), в то время как в ДБО 2.0 была впервые применена микросервисная ИТ-архитектура.

• В системах уровня АБС (ЦФТ, БИСквит, мБанк) использовалась клиент Серверная архитектура.

Таким образом, несмотря на то, что ИТ-архитектура 2019 года могла решать актуальные, на тот момент задачи, она обладала определенными недостатками, которые не позволяли банку перейти на качественно новый уровень развития. Здесь также необходимо отметить уровень надежности, который составлял тогда 99,6% с 35 часами простоя в год и не способствовал созданию положительного цифрового клиентского опыта.

Но в чем еще заключалась основная проблема той архитектуры, кроме надежности? Предлагаю взглянуть на линию обслуживания клиентов в приложениях для сотрудников и приложениях дистанционного обслуживания, кратко именуемой «фронт» такой организации. Там два ключевых игрока — владельцы этих фронтальных приложений и продуктовые команды.

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

ФРАГМЕНТАЦИЯ КЛИЕНТСКОГО ОПЫТА

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

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

ПРЕДЕЛ ПРОИЗВОДИТЕЛЬНОСТИ ИТ

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

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

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

УХУДШЕНИЕ КЛИЕНТСКОГО ОПЫТА

Отсутствие унификации и единого, для всех, процесса усложняет создание положительного и последовательного клиентского опыта, так как каждый представляет продукт по-своему.

ЗАДЕРЖКА И ОГРАНИЧЕНИЕ СКОРОСТИ ВЫВОДА ПРОДУКТА НА РЫНОК

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

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

Она позволяет не только оптимизировать внутренние процессы для обеспечения единообразия и ускорения вывода продуктов на рынок, но и значительно повышает качество клиентского сервиса, делая его более привлекательным для потребителей.

Движемся дальше!

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

Можно провести аналогию с магазином, где ВТБ выступает как универсальный магазин с разнообразными витринами (канальными приложениями — такими, как ВТБ Online, ВТБ Рго, чатбот и т.д.). И где продуктовые команды (например, реализующие переводы физическим, юридическим лицам, расчетно-кассовое обслуживание и даже деривативы) самостоятельно размещают свои продукты на этих витринах.

Разумеется, все это происходит с соблюдением общих правил «магазина» и с учетом технологических особенностей «витрин». Такая схема распределения работ по реализации фронтальной логики между командами решает сразу две задачи:

• Снимает нагрузку с команд фронтальных систем, которые больше не являются «бутылочным горлышком» процесса;

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

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

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

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

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

Омниканальные системы, называемые сервисами устойчивых бизнес операций (СУБО), в которых реализованы уникальные процессы, и сервисы конкретных продуктов выводятся в эти самые каналы. В СУБО продуктовые процессы определяются продуктовыми командами и не зависят от внешних факторов и решений, при этом соблюдаются общие правила «магазина» — стиль, дизайн, графика. Это дает владельцу продукта пространство для фантазии и творчества.

Тем не менее, в продуктовых процессах существуют общие потребности, такие как получение продуктового профиля (данные по продуктам клиента), выполнение проверок по ПОД/ФТ, выписка по счету, нотификация по цифровым каналам (eMail, PUSH, SMS), по событию и так далее. Было бы нецелесообразно реализовывать такие общеиспользуемые функции несколько раз в различных системах.

Для этих целей в омниканальной архитектуре предусмотрен слой общих сервисов.

Общие сервисы бывают:

• как содержащие продуктовую банковскую специфику и логику (выписка по счету, перевод, блокировка счета и т.д.) — это общий продуктовый сервис (ОПС);

• как непривязанные к банковской деятельности и полезные для других бизнесов, не только банковских. Например, работа с клиентскими данными, регуляторные проверки, управление медиаконтентом и т.д. — это общие сервисы (ОС).

О них мы подробно поговорим дальше.

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

Таким образом, на слое «Канальное приложение» КП/СУБО/ОПС формируется клиентский опыт, что является полем деятельности продуктовых команд и владельцев продуктов.

Слой же общих (ОС) и служебных сервисов (СС) относится к платформенным сервисам, который полезен всем и может быть применен не только в ВТБ, с его продуктовой спецификой, но и в других банках или даже в других типах организаций, например, в страховой компании, лизинге или в футбольном клубе «Динамо».

Так выглядит структура Омниканальной архитектуры.

Теперь я расскажу о трёх базовых Омнипринципах.

ПЕРВЫЙ ПРИНЦИП

Вся специфика и творчество продуктовых команд концентрируется на слое сервисов устойчивых бизнес-операций.

ВТОРОЙ ПРИНЦИП

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

ТРЕТИЙ ПРИНЦИП

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

Таким образом, омниканальная архитектура — это…

• не просто структура — канальные приложения, сервисы устойчивых бизнес операций, общие продуктовые, общие и служебные сервисы,

  ● но и связи, где СУБО выводятся в канальные приложения и используют возможности ОПС, ОС и СС.

Теперь, когда мы понимаем основы омниканальной архитектуры, мы готовы погрузиться на следующий уровень детализации этой архитектурной модели.