Форум открылся секцией «Вызовы рынка — 2018», смысловая насыщенность которой задала тон всем последующим обсуждениям IT-проблематики, обозначив и основные проблемные узлы индустрии, и тренды, и прецеденты наиболее интересных решений.

Фото: FutureBanking

Секция началась докладом Сергея Лукашкина, директора по управлению проектами цифровой трансформации ВТБ, посвященного умной автоматизации.

На основе AI создаются чат-боты, проводятся скоринг и поиск ошибок в документах, строится вся биометрия. Инструменты RPA позволяют сократить затраты на персонал, при этом дают возможность оптимизировать и масштабировать бизнес-процессы точечно, не дожидаясь разворачивания дорогих и длительных работ по замене «тяжелой» легаси-системы. В финансовой отрасли начинают применять Интернет вещей (Iot), снимая данные с различных датчиков. По мере развития технологии 5G Интернет вещей будет распространяться все шире, обеспечивая автоматизированные платежи при работе с гарантиями и документами цепочек поставок, в факторинге, в переводых по аккредитивам. DLT (distributed ledger technology) применяется и будет применяться в области платежей и банковских документарных операциях.

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

«Что происходит на рынке?» — начал свое выступление Александр Генцис, член совета директоров компании «Диасофт».

При всем хайпе вокруг цифровизации реально успешных проектов очень мало. Одна из главных причин — резкий рост плотности транзакций при переходе на ДБО. Многие люди пользуются сегодня мобильным банкингом чуть ли не ежечасно. Это ведет, в свою очередь, к кратно возрастающей нагрузке на базовые банковские IT-инфраструктуры — те самые легаси-системы, которые создавались 30 лет назад в расчете на тогдашние объемы обрабатываемой информации. Нагрузка будет усиливаться с расширением ДБО, а именно такой тренд задают необанки: переход от офлайн-отделений к цифровым офисам, а затем и к маркетплейсам. Чтобы справиться с ситуацией, банкам необходимо разделить IT-архитектуру на два слоя — на систему обеспечения работы бэк-офиса и систему обеспечения фронт-офиса. Система бэк-офиса должна быть централизованной, от нее требуются надежность, производительность, наличие открытого API и интегрируемость с IT-ландшафтом, линейная масштабируемость, поддержка сквозных бизнес-процессов и доступность в режиме 24х7. А вот система фронт-офиса, которая напрямую связана с цифровой трансформацией, должна быть децентрализованной и бесконечно гибкой. Компания «Диасофт» билась над проблемой несколько лет и вложила в разработки 30 млн долларов. На сегодняшний день, по словам Александра Генциса, успешно завершено два крупных проекта по IT-перевооружению банков, и сегодня «Диасофт» предлагает рынку на выбор два варианта. Первый, традиционный, — промышленное решение от вендора с доработкой под специфику конкретного банка. Второй, необычный и во многом революционный, — совместная разработка, в ходе которой «Диасофт» готов раскрывать свои ноу-хау, обучать специалистов заказчика работе в кросс-функциональных командах и запускать командную работу в смешанном составе: специалисты «Диасофт» и сотрудники банка-заказчика. Результат — совместно построенная для банка фабрика по производству цифровых продуктов.

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

Фото: FutureBanking

Случаев, когда бизнес-IT-системы работают в режиме постоянного апгрейда архитектуры со стороны вендора, не так много. Чаще системы, будучи однажды внедренными, живут внутри банка, дописываются и модифицируются собственными силами. Они работают безупречно в лучшем случае 15–20 лет, после чего начинаются сюрпризы. Критический сбой, означающий не только непригодность системы к дальнейшему использованию, но и удар по бизнесу, может произойти через 20–30 лет. Большинство банковских систем создавалось в конце 90-х — начале 2000-х. Для того времени это было последнее слово прогресса, но сегодня срок их жизни заканчивается. Где те, кто их дописывал, переписывал и мог бы починить то, что не заладилось? Их давно уже нет в компании. Продолжительность активной карьеры IT-специалиста приблизительно совпадает с жизненным циклом IT-систем: 20–30 лет.

Сегодня в бизнес приходит поколение разработчиков с другими знаниями и иной подготовкой. Их невозможно заставить копаться в устаревших легаси-системах, старые технологии они не воспринимают: «Не хочу Oracle, хочу React и Hadoop!» Сейчас кадровая и технологическая ситуация такова, что банкам впору полностью менять устаревшие системы. Желательно без экспромтов и революций со всеми их рисками. По мысли Сергея Путятинского, банкам целесообразно каждые 15–20 лет задумываться об обновлении архитектурного стека и начинать долгосрочный проект, чтобы через два-три года запускать полностью обновленную архитектуру.

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

При всем хайпе вокруг цифровизации реально успешных проектов очень мало

По ходу доклада Сергей Путятинский привел два кейса. Один — кейс-катастрофа, когда старую систему финансового обслуживания пенсионеров оказалось некому поддерживать и развивать. Другой — пример безболезненного решения: замена системы была инициирована в 2015 году, к 2016-му построена модульная масштабируемая платформа на Java, а в 2019-м плавный переход на новую архитектуру будет полностью завершен.

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

В аналитическом блоке используются OLAP-системы, обычно — классический DWH (ETL, DOS, Bi) со всеми проблемами долгой перегрузки данных и высокой стоимостью изменения моделей данных и хранилищ.

Средства автоматизации принятия решений — например, о выдаче кредита — построены, как правило, на детерминированных алгоритмах «если — то». Это в основном NBO, Fraud Prevention, SOC, которые решают лишь ограниченный класс не слишком сложных задач.

Сопоставляя эти особенности с требованиями рынка, Олег Баранов пришел к неутешительному выводу: для IT-ландшафта рядового российского банка характерны сильная связанность, дороговизна и низкая скорость внесения изменений, низкая скорость работы IT-систем, сложность масштабирования, невозможность работы с неструктурированными данными.

Фото: FutureBanking

Организациям, которые задумываются о происходящем вокруг, хорошо известно о существовании современных технологий. Они думают в этом направлении, пытаются делать первые шаги. Обобщая наблюдения за рынком и собственный опыт, Олег Баранов назвал основные инструменты для IT-обновления банков: микросервисная архитектура вместо монолита, Big Data и streaming вместо OLAP и OLTP, AI вместо детерминированных алгоритмов.

Сергей Степанов, начальник управления корпоративной IT-архитектуры Росбанка посетовал на то, что иногда банки занимаются IT-обновлением, никак не увязывая свое желание с бизнес-задачами и бизнес-результатами. Он поделился своими размышлениями на эту тему. То, что сегодня у всех на слуху, — микросервисы, API, блокчейн, Big Data, ML, BPMS/BRMS, containers — это всего лишь инструменты. Они нужны для того, чтобы реализовать новые бизнес-принципы: Open-API-партнерства и data-партнерства, маркетплейс, мультиканальность, data factory, time-to-market. Для чего? Чтобы создавать новые бизнес-модели.

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

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

Фото: FutureBanking

Одна из острейших проблем новой ситуации: новая модель потребления перемещает точку доверенного контакта с клиентом за периметр банка. Туда же уходит и управление клиентской базой, и управление ценообразованием. Теперь владелец платформы решает, какие клиенты будут использовать продукты банка и в каких процессах. А банки — перед выбором. Хочет банк стать только поставщиком услуги или еще и владельцем платформы? Росбанк будет строить свою платформу потребления для клиентов и одновременно расширять продажи через внешние платформы. Сергей Степанов рассказал, как в Росбанке видят целевую архитектуру: централизованный слой на основе Big Data, умеренно децентрализованный слой приложений для регистрации сделок и распределенный слой сервисов и процессов обслуживания клиентов, построенный по микросервисной модели. Предполагается также слой API, открытый для разработки собственных приложений банка, для партнеров, для внешних платформ.

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

Дмитрий Свалов, технический директор компании BSS, презентовал новую платформу Digital2Go для цифровых банковских решений. За последнее полгода силами четырех кросс-функциональных команд BSS, используя возможности Digital2Go, создала решения, вошедшие в топ-5 рейтинга Markswebb в трех категориях.

К настоящему времени на Digital2Go реализовано четыре решения: для малого и среднего бизнеса, для корпоративных клиентов, для частных клиентов, для пользователей мобильных приложений. Дмитрий Свалов рассказал о количественных показателях масштабируемости, надежности и производительности платформы, о типовой схеме развертывания продуктов на базе Digital2Go. Клиенты обращаются к системе через Интернет и, работая с ней, как с конструктором, разворачивают функционал с нужными процессами и характеристиками. Платформа открытая, оснащена инструментами для доработки заказчиками. Коробочные продукты заказчик может кастомизировать как самостоятельно, так и совместно с BSS, для этого выделен отдельный слой. Использовано также инновационное решение, благодаря которому заказчики cмогут самостоятельно и без программистов решать широкий класс задач. Предусмотрены система электронного обучения и краткий курс прикладной разработки.

Подытожим. Почему IT-мозги банка должны быть обязательно модульными и обязательно слоеными? Послойное устройство подобно конструкции дома: позволяет ремонтировать кровлю, не трогая стены, а занимаясь стенами, не разбирать пол и не перезаливать фундамент. Послойность — наиболее экономичный принцип, потому что разные виды работ стоят разных денег и необходимость в них возникает в разные сроки. Что же касается модульности — вспомним старого доброго Генри Форда, который с помощью конвейера резко повысил производительность сборочного производства. Смысл в том, чтобы работники занимались каждый своей частью общей сложной работы, не толкаясь локтями и не мешая друг другу. Вероятно, обдумывая конструкцию для «Формулы-1», инженеры не в последнюю очередь учитывают удобство работы команды, которая, набросившись на болид, в считанные секунды меняет колеса. Все сразу не могут заниматься всем сразу! Модульность — это возможность для «боевых единиц» — небольших команд разработчиков — быстро и точечно модифицировать и достраивать достаточно узкий функционал. Не погружаясь в то, что напрямую с этим функционалом не связано и не вторгаясь в блоки, над которыми бьются другие команды.