Банковское обозрение

Почему подход «от ТЗ — к исполнению» не работает с Big Data? Как побороть сакральное «где карту открывали, туда и обращайтесь»? Что общего у диджитализации с покупкой шампанского? Ответы — у ведущих экспертов по IT-трансформации банковской платформы

Место встречи — Data Lake

О том, как построить озеро данных, рассказывал начальник управления технологий сбора и хранения данных департамента банковских и информационных технологий ВТБ24 Дмитрий Первухин. Data Lake сегодня — это свыше 60 млн клиентских записей, 15 млн активных клиентов, 8 розничных филиалов, 1300 точек, 15 тыс. банкоматов, более 100 тыс. pos-терминалов и свыше 31 тысячи сотрудников. Все это генерирует огромный массив данных: в ближайшие два-три года их объем в информационных системах достигнет некого зеттабайта с огромным количеством нулей. «Отсюда вывод: текущие технологии построения хранилищ данных, особенно в корпорациях со сложной IT-инфраструктурой, не способны угнаться за ростом данных и за изменением самих данных и систем, которые их порождают», — сформулировал Дмитрий Первухин.

Дмитрий Первухин, ВТБ24

Высокая скорость накопления данных приводит как минимум к двум проблемам: высокой стоимости владения (хранение 1 терабайта обойдется в сумму около 30 тыс. долларов) и к тому, что данные окажутся недоступными для моделирования и анализа. «Мы постоянно испытываем прессинг со стороны пользователей, аналитиков: мол, вы делаете IT долго и некачественно, — признается Первухин. — Исполнитель исходит из парадигмы “вы сначала объясните задачу, а мы потом начнем работу”. Но реалии таковы, что в 80% случаев клиентам нужен не отчет, им нужно понять, если ли смысл в использовании этой информации, и, если да, то они готовы сформулировать требования к построению автоматизированной системы. Получается, что пользователи не могут понять, чего они хотят, а мы соответственно не можем это сделать. Следствие — низкий показатель time-to-market. Зачастую заказчиков уже нет в банке, когда подходит реализация и выгружаются данные».

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

«Пора уже осознать, что Big Data — это не просто много данных, это способ переформатировать IT-мышление, — предлагает выход эксперт. — Заказчикам нужно понять ценность данных, их получить, пощупать, и дальше уже формулировать бизнес-задачу. Важно перейти от проектирования по схеме “сначала ТЗ — потом реализация” к постоянным натурным испытаниям данных. “Что будет, если мы вам выложим вот это? Что вы с ним хотите делать?”. Ну и дальше происходит итерационная работа, где обе стороны уточняют: одни — свои возможности, другие — свои потребности. Главный вывод расширения текущего хранилища данных до Data Lake: нужно отказаться от бесплодной борьбы за качество данных и рассматривать озера просто как технологическую площадку взаимодействия специалистов, которые понимают, как положить и извлечь данные, с теми, кто представляет, как их использовать».

Ядро прогресса

«Основные тенденции финансового рынка — тотальная диджитализация, наступление небанковских игроков, постоянное ужесточение требований регуляторов и глобализация участников рынка», — перечисляет главный бизнес-архитектор департамента «Финансовые рынки Flextera» компании «Диасофт» Наталья Татарникова. Более 26 лет ее компания занимается банковским ядром и наблюдает за тем, как коробочные решения превращаются в легенду: «Для крупных игроков бизнес-процессы уникальны, им нужны не коробки, а сервисы, которые можно объединить в нужные решения».

Наталья Татарникова, «Диасофт»

Вот каким «Диасофт» видит ядро банковской системы: во-первых, централизованным, во-вторых, компонентным — не монолитная система, а компоненты, которые можно обновлять, развивать, добавлять независимо друг от друга. Третьей характеристикой эффективного ядра считают его спроектированность от бизнес-процессов. «О процессах всегда говорят во фронте. Но если процесс из фронта опускается в бэк-офис, а он такого слова не знает, то работать ничего не будет. Или будет один раз — во время запуска. Потом, когда потребуется что-то развивать, нужно будет затратить еще столько же сил. В результате теряется скорость обновления бизнес-процессов во фронте», — заявляет Татарникова. Четвертым качеством ядра должна стать его линейная масштабируемость, а это — вопрос платформы, на которой оно строится. «Допустим, мы централизуем банк, где до этого было 50 книг, а теперь нам нужно сделать одну головную книгу на сервисе какого-то финансового ядра. Естественно, требования к производительности вырастают, — продолжает эксперт. — Ядро должно работать очень быстро, давать хороший отклик и быть линейно масштабируемым, чтобы банк мог прогнозировать расходы на железо по мере роста бизнеса».

Коснулась Татарникова и вопроса банковской централизации, пошутив, что «можно сколько угодно говорить про каналы, про мобильные банки, но если в отделении говорят: “Где карту открывали, туда и идите”, о какой диджитализации мы тут говорим?» Преодолеть проблему, опять же, способно качественное ядро. В первую очередь на нем нужно создать централизованный бэк-офис. Это значит — все договоры, сделки, операции должны лежать в одном центральном месте. Внутри бэк-офиса можно делать уже более сложную архитектуру. «Кроме того, необходим централизованный учет, — говорит эксперт «Диасофта». — Это как разговор о 50 разных книгах, которые потом сливаются в одну с потерями во времени и в данных. Крупные банки никогда не знают на конец дня свой точный баланс. Налицо проблема для прогнозирования и других данных, которые строятся на учетных параметрах. Далее — единая отчетность. Это не новость, но строить единую отчетность на централизованном учете — это совсем другая, более легкая задача».

«Никакая диджитализация на старом ядре не заработает», — подчеркивает Татарникова и приводит в пример еще и бизнес-процессы. «Если у нас есть фронт-офис, который взаимодействует с огромным количеством каналов, то взаимодействие с бэк-офисом может быть затруднено. А если бэк внутри тоже выстроен по процессам, то тогда и обратный поток будет гибкий и прямой. Вывод: у нас разные причины, почему нам нужно высокопроизводительное ядро. Но в итоге оно нужно всем».

Сервис на автомате

О требовательности клиентов и необходимости предоставления банковского сервиса в формате 24/7 рассуждал директор развития программного обеспечения и архитектуры Хоум Кредит Банка Михаил Кононов. По его мнению, на пути к круглосуточному сервису банк подстерегают следующие проблемы: слишком большое количество процессов по закрытию операционного дня/месяца и недоступность АБС банка из-за технологических операций. «Большинство существующих АБС, которые встречаются в IT-ландшафтах банка, на время проведения технологических операций блокируют другие процессы изменения данных». Если банк не хочет идти по пути внедрения новой АБС, эксперт предлагает сделать следующее:

• вынести клиентские данные в системы, не выполняющие никаких периодических процессов;

• использовать stand-by базы данных продуктовых и автоматизированных банковских систем, а в дальнейшем — онлайн-репликацию;

• кэшировать запросы клиентов на активные операции, внедрять модуль accounting engine — определенные онлайн-процессы полностью вынести из автоматизированных банковских систем.

Михаил Кононов, Хоум Кредит Банк

«Мы научились делать определенные сервисы для наших клиентов на время технологических операций. С помощью источников данных на интеграционных сервисах мы переключаем банк с основных production-баз данных на локальные копии на stand-by», — рассказал Михаил Кононов. По словам эксперта, чтобы обеспечить клиентов активными операциями, в банке обязательно должен быть внедрен модуль accounting engine. «В начале это может быть простая очередь, в которую кэшируются запросы на проведение активных операций. По мере подъема автоматизированных банковских систем эти запросы будут проливаться в них. В дальнейшем в таком модуле вы должны вести актуальные остатки счетов и осуществлять активные операции».

Шампанское отдельно

«Сайт банка, маркетплейс, ДБО, интернет-банк, мобильный банк: для клиента все это — один и тот же банк, но попытка объединить все его составные части нередко упирается в отсутствие взаимопонимания внутри компании. Люди вроде бы занимаются общим делом, но у них разные KPI, — рассказывает о проблеме руководитель департамента «Цифровой банк» банка «Уралсиб» Александр Сахаров. — В итоге получается Data Lake, с которым невозможно ничего сделать. Он хорош для аналитики, а в транзакционном бизнесе, когда одна и та же кнопка должна по-разному показываться одному клиенту, с Data Lake не получается». В качестве примера эксперт приводит собственный клиентский опыт — покупателя в магазине у дома, где алкоголь продается отдельно от остальных товаров: «Я — один и тот же клиент, но, если покупаю шампанское и шоколадку, у меня очень неудобный процесс. Меня ни там не знают, ни здесь, везде просят карту покупателя. У них, видите ли, разные KPI и разные интерфейсы взаимодействия».

Александр Сахаров, «Уралсиб»

По мнению Сахарова, взаимодействие клиента с банком требует единой логики и единых правил: «Заходя на сайт или в мобильный банк, клиент не должен быть вынужден заново вводить свой, условно, ИНН. Это возможно, когда все его действия учитываются в единой экосистеме, под которой лежат единые источники данных, единый логин».

Говоря о фронт-энде, эксперт насчитывает четыре независимые системы, которые делают разные вещи с одними и теми же данными. «Мы на этот слой поставили единую фронтальную штуковину, которая параллельно обладает механизмами обогащения данных из Интернета. А вот на уровне API все разбито по конкретным функциональным кускам. Чисто рублевые платежи, валютные платежи, валютный контроль, узкопрофессиональное API под нашего партнера по интернет-банку. Каждое из них должно быть интуитивно понятно программистам. Люди, которые работают во фронте, не знают, что такое проверка разрядности счета, правила валютного контроля, ввода платежки и так далее. Все эти подсказки должны быть наследованы из API», — подытожил Александр Сахаров.

Грабли альпинистов

О своем опыте построения архитектуры цифрового банка рассказал CIO Touch Bank Михаил Алексин. Он сравнил диджитализацию с альпинизмом: «Когда начинаешь этот путь, приходится преодолевать тяготы и невзгоды, ведь на большой высоте кислорода немного, а нагрузки высокие. Успех сопутствует единицам. Во всем мире диджитал-банки активно хвастаются наработанной клиентской базой, опытом, но очень скромно говорят о финансовых успехах. Почерпнуть опыт из книг, общения с коллегами почти невозможно — шишки приходится набивать самостоятельно. Каждая ошибка, каждые “грабли” должны стать опытом».

Михаил Алексин, Touch Bank

Говоря о своих ошибках, Алексин назвал суждение, что существующие на рынке системы можно «насыпать в банку, налить клея, потрясти, и внутри соберется чудесный кораблик». Иначе говоря, из решений, которые уже есть на рынке, невозможно создать что-то новое: это уже не новинка. Следующими своими «граблями» Touch Bank называет надежду, что, если призвать в технологическое партнерство лидеров отрасли, то можно будет использовать не только их технологический опыт, но и их отраслевую экспертизу. «Не полетело. С предоставлением полной свободы не заработало», — резюмирует эксперт.

На пути к диджитализации Touch Bank выбрал соло-архитектуру с композитными сервисами на базе стека технологий IBM. «Возможно, это позволило нам быстро подняться до базового лагеря, но дальше начались сложности. Сложность внесения изменений: чтобы дотащить до ДБО новую бизнес-фичу, удовлетворить клиентский запрос, надо было произвести синхронные изменения как минимум в пяти системах. Помимо этого — их интегрировать. Это привело к дороговизне эксплуатации, проблемам со стабильностью. По мере внесения изменений все больше и больше требовалось производить рефакторинг ранее написанного. Стало понятно, что скоро мы там закопаемся». По словам Михаила Алексина, архитектура сильно ограничила Банку свободу в выборе средств реализации — например, языков разработки.

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

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