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

А начнем мы с аббревиатур, чтобы было понятно, о чем идет речь:

• ОПС — общие продуктовые сервисы

• ОС — общие сервисы

• СС — служебные сервисы

• КП — канальные приложения

• СУБО — сервисы устойчивых бизнес операций

• РИС — реестр информационных систем

• ГБЛ — глобальная бизнес линия

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

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

Здесь вы видите ИТ-архитектуру банка поколения 4++. Есть сервисный слой и интеграционная платформа, что соответствует пятому поколению по классификации, упомянутой в начале моего рассказа об Архитектуре. Однако присутствует и слой сервис-провайдеров, созданных в двух- и трехзвенной архитектуре, который все еще относится к четвертому поколению.

 Далее мы обсудим,

• Что мы делаем с этим слоем для перехода к пятому поколению архитектуры организации;

• И как в этих условиях развивать ИТ-ландшафт банка для достижения целей цифровой трансформации.

Рассматривать омниканальную архитектуру банка мы будем «по слоям». В начале разберемся, что такое каналы в омниканальной архитектуре. Каналы для организации, особенно специализирующейся на обслуживании клиентов, являются жизненно важной частью — лицом организации. Каналы предоставляют технологическую возможность взаимодействия с пользователями, с учетом конкретной технологии: Web, мобильные устройства, чат-боты и т.д.

Какую роль каналы играют в ИТ-архитектуре, какие возможности дают и какие особенности необходимо учитывать? Базовый момент: в каналах не должно быть продуктовой логики. Канал в первую очередь — это технологический способ взаимодействия с клиентом.

Таким образом, каналы — это:

• Технологические возможности ИТ-ландшафта для организации взаимодействия с клиентами и сотрудниками организации, например, web или мобильное приложение, телефон, SMS, PUSH — все современные технические способы коммуникации; 

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

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

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

• Самообслуживание;

• Устройства;

• Точки продаж;

• Удаленные продажи;

• Партнерские каналы.

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

Каналы — это технологические возможности, и они обладают собственной спецификой:

• Синхронное и асинхронное взаимодействие. Каналы обслуживания могут работать в режиме реального времени (синхронно), когда клиент получает ответ сразу после запроса, например, в мобильных приложениях при запросе выписки. В отличие от этого, асинхронные каналы, такие как SMS или электронная почта, реализуют отложенное взаимодействие, где ответ приходит не сразу после запроса;

• География каналов. Некоторые каналы связаны с физическим местоположением банка, например, точки продаж, где клиент общается с банком на его территории. В то время как другие каналы зависят от местоположения клиента (мобильное устройство), что позволяет банку знать, где клиент находится в данный момент;

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

• Взаимодействие с человеком или роботом. Некоторые каналы предусматривают общение клиента с сотрудником-человеком, в то время как другие используют автоматизированные системы (роботов). Важно правильно использовать преимущества каждого типа взаимодействия:

  o   Личное общение может быть более эффективным, когда требуется вовлечение и персонализация, и в общении заинтересован банк;

  o   А роботы могут быть удобнее, когда клиенту нужно быстро выполнить стандартные операции без необходимости персонального контакта.

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

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

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

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

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

Основной функционал продуктовых процессов для повторного использования включает такие общие продуктовые сервисы, как «Продуктовые профили» для физических и юридических лиц, которые содержат данные по всем продуктам клиента, или «Платежи физических лиц», широко используемые в ВТБ Online. Эти продукты и сервисы выводятся во все канальные приложения, которые требуются будь то интернет-банкинг, мобильный банк или ВТБ Про, в соответствии с архитектурой омниканальности. Так мы размещаем продукты на «витринах магазинов».

Такая структура создает в этой архитектуре различные «башенки» с определенными функциями:

• Продажи и обслуживание банковских продуктов как часть цифровой банковской платформы;

• Кредитные конвейеры;

• Внутренние операции;

• Казначейство;

• Операционная деятельность.

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

А где общее для всех башенок вне зависимости от их назначения? На слое нашей омниплатформы общее для всех ГФЛ (глобальная функциональная линия): отправить нотификацию, проверить по черным спискам. Одна из ключевых ценностей сервисной организации — клиентские данные физических и юридических лиц.

Для ИТ-специалистов в омниканльной архитектуре предусмотрены цифровые инструменты производства:

• Служебные сервисы, которые выполняют общие прикладные задачи: мониторинг, маршрутизацию, журналирование и управление через административные консоли;

• Все это базируется на едином технологическом стеке, который соответствует стандартам и корпоративным ценностям ВТБ.

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

• Кому нужен банковский бизнес, возьмет все целиком — и КП, и СУБО, и все остальное;

• Кто-то хочет все тоже самое, но переделать процессы — пожалуйста, линия отреза ОПС. Создаешь свои КП и СУБО, а остальное (ОПС/ОС /СС) переиспользуешь;

• Если создаешь ИТ-ландшафт для металлургического завода, возьми только ОС и СС, а логику напиши свою.

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

Все элементы платформы — это реальные системы в нашем Реестре информационных систем (РИС). Вы сами можете увидеть платформу в РИС: тип элемента указан в столбце «Категория системы».

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