От чего зависит скорость вывода решений на рынок, управляемость бизнеса и качество клиентского опыта? Об этом рассказали лидер архитектурного совета АФТ, начальник отдела ИТ-архитектуры Райффайзенбанка Дмитрий Клецких, заместитель Председателя Правления ПАО «БАНК УРАЛСИБ» Станислав Тывес и старший менеджер практики Software Engineering в Axenix Дмитрий Кузнецов.
Старший менеджер практики Software Engineering в Axenix
Продуктовый каталог с нуля
Основная цель продуктового каталога — централизованно хранить данные, структурировать их, управлять жизненным циклом (создание, изменение, архивирование), версионностью и аудитом. Но как только эта база создана, возникает задача по распространению этих знаний по всему IT-ландшафту через интеграции: каталог начинает обслуживать каналы продаж, кредитные конвейеры, системы принятия решений и аналитические платформы. По мнению Дмитрия Кузнецова , на рынке фактически нет готовых решений, полностью закрывающих потребности банков, поэтому компании разрабатывают продуктовые каталоги самостоятельно, с высокой долей кастомизации.
Главная сложность при создании продуктового каталога в формализации данных о продуктах. Даже базовые элементы, такие как списки значений (например, категории клиентов или отделения), оказываются справочниками, которые должны быть синхронизированы со всеми системами. Попытка решать это локально почти всегда приводит к проблемам, поэтому требуется либо использование централизованных справочников, либо создание отдельной системы управления ими.
Аналогичная ситуация с иерархией продуктов: простой «плоский» список не работает, нужна гибкая древовидная структура с возможностью неограниченного расширения. Но здесь возникают сложности из-за правил наследования атрибутов, массовых изменений, контроля целостности данных и предотвращения конфликтов. Поэтому важна аналитика, не автоматизированная, а «ручная», чтобы знать размер продуктовой линейки, общие и частные параметры продуктов. Это позволит создать правильную структуру «дерева».
Следующий уровень — управление связями между продуктами и условиями их применения. То есть формирование комбо-предложений или скидок требует не просто описания продуктов, а моделирования логики взаимодействия между ними. Например, есть два продукта с определенной атрибутикой (ипотека и более дешевая ипотека со страховкой). Задача — формализовать это так, чтобы можно было перезаписываемые атрибуты накладывать на связи между продуктами. Появляются механизмы условий: скидки, надбавки, правила их применения, приоритеты, агрегирующие формулы. Фактически речь идет о построении отдельного расчетного движка внутри каталога, который в зависимости от контекста (тип клиента, параметры сделки, внешние условия) выдает релевантное предложение.
Дополнительно каталог начинает выполнять функции, выходящие за рамки хранения данных. Кредитный калькулятор в такой архитектуре не просто интерфейс с формулой, а инструмент, который работает на основе актуальных данных каталога, с учетом ограничений, акций и параметров продуктов. Аналогично реализуются механизмы подбора альтернатив: если клиенту не подходит один продукт, система должна предложить другой, опираясь на заданные правила или даже на рекомендательные модели.
Отдельный пласт — расчетные показатели. Вместо хранения всех возможных комбинаций параметров, что приводит к экспоненциальному росту записей, система может рассчитывать значения на лету, используя формулы и агрегаты. Это позволяет радикально сократить объем данных и упростить управление каталогом. По мере усложнения системы возникает необходимость в управлении доступом и процессами. Создание продукта превращается в многоэтапный workflow с ролями, согласованиями и интеграциями.
В итоге продуктовый каталог из вспомогательной системы становится полноценной платформой, которая объединяет данные, бизнес-логику и интеграции. Идеальных решений при создании продуктового каталога нет. Но в его разработку стоит вкладываться, так как она обеспечивает гибкость продуктовой линейки, влияет на эффективность продаж и позволяет планировать внедрение ИИ-инструментов.
Заместитель Председателя Правления ПАО «БАНК УРАЛСИБ»
Гибкость как залог успеха продуктовой фабрики
Станислав Тывес отмечает, что настройка взаимодействия ключевых блоков для создания банковских продуктов определяет успех работы продуктовой фабрики в целом: «Гибкость влияет на скорость, с которой продукт выходит на рынок. Поэтому взаимодействие всех ИТ-модулей фабрики критически важно».
В «Уралсибе» стратегию продукта определяют три комитета и главный критерий, которым они руководствуются, — доходность продукта для акционера. Комитет по управлению активами и пассивами устанавливает минимальный коэффициент возврата на капитал и стоимость фондирования. Кредитный комитет решает, сколько готовы потерять в случае неудачи. Исходя из этих показателей, продуктовый комитет определяет параметры продукта и его маржинальность. В параметрах учитываются специфика и потребности каждого сегмента — B2B или B2C. Есть продукты, которые необходимо просчитать на оба сегмента, например автокредиты. Они продаются через партнеров и должны нравиться всем: и клиентам, и партнерам.
Маржинальность каждого продукта зависит от множества факторов, и отклонение по одному из них может драматически повлиять на результат. По набору критериев маржинальности самый сложный продукт — кредитная карта. При подготовке текущей модели по кредитным картам в «Уралсибе» используют 38 переменных. Есть основные переменные, такие, например, как размер кредитного лимита, уровень активации и утилизации, доля POS-транзакций, доля пользователей льготного периода, а есть переменные для моделей для разных каналов продаж.
Модель позволяет увидеть, как изменятся остальные показатели, если, например, вырастет стоимость риска. Все параметры совмещаются с параметрами каналов продаж — каждый показывает разную доходность. В разные моменты выгодны разные каналы продаж. На маркетплейсе может быть высокая конкуренция за выдачу кредитной карты, значит, комиссия тоже выше. Тогда выгоднее минимизировать выдачу через этот канал, но прокачать собственные возможности банка по продаже кредитных карт. Для контроля целевых показателей реализованы отчеты на каждом этапе жизни продукта.
В работе продуктового конвейера важно не только создание гипотез, но и умение увидеть в результате, который выдает модель, новую структуру взаимодействия параметров. Каждый тест гипотезы увеличивает базу знаний, даже если гипотеза не подтвердилась.
Над всем этим работают 22 кросс-функциональные команды разработки. Но несмотря на смешивание специализаций сотрудников в командах, зоны ответственности ИТ и бизнеса четко разделены. Продуктовый каталог позволяет всем командам видеть, что происходит в разработке, всю кредитную и тарифную политику и быстро менять продукты при необходимости.
Лидер архитектурного совета АФТ, начальник отдела ИТ-архитектуры Райффайзенбанка
Ориентир будущего: самоуправляемый банк
Дмитрий Клецких обращает внимание на то, что банки переходят от продуктовой agile-модели к AI-native-архитектуре, которая постепенно передает ключевые решения от автоматизированных систем к искусственному интеллекту. Предыдущая трансформация — смена функциональной модели на продуктовую — сделала команды автономнее, нарастила скорость вывода решений на рынок (time-to-market) и гибкость разработки. Но при этом резко увеличила сложность ИТ-ландшафта и снизила управляемость. Возникли дублирующие решения, риски надежности, а классические практики IT governance начали деградировать из-за фокуса команд на собственных P&L. На этом фоне внедрение ИИ и повышение автономности становятся необходимостью для удержания контроля над системой.
Новая стратегия реализует концепцию «самоуправляемого» банка, который использует ИИ, машинное обучение и аналитику данных для управления финансами клиента с минимальным участием человека. У человека в этой модели роль архитектора, а не оператора. Успех реализации такойSelf-Driving стратегии можно будет оценивать по трем ключевым метрикам. Во-первых, автономность: чем меньше ручного участия в операционных процессах (RUN), тем лучше, вплоть до полного отсутствия человеческого контакта. Во-вторых, скорость вывода решений — time-to-market: амбициозная цель — довести его до 1–2 дней. В-третьих, персонализация: клиент принадлежит сегменту, и продукты под него собираются индивидуально.
Переход к такой модели осложнен системными ограничениями. Устаревший legacy ИТ-ландшафт плохо приспособлен для работы с ИИ; не хватает контекста — как бизнесового, так и данных, инженерной информации; есть ограничения, связанные с импортозамещением. В этом же списке организационные издержки — избыточное взаимодействие между командами, замедляющее процессы, прежде всего связанные с производством ПО. И сами технологии ИИ пока не обеспечивают необходимого уровня зрелости, так как чаще встраиваются в продукт как опция, а не являются его основой.
Но банки постепенно переключаются на создание AI-native-продуктов. Ключевыми практиками становятся сбор и структурирование данных для ИИ или context engineering: способность системы собирать, структурировать и использовать контекст, чтобы машина могла оценить и сопоставить события в бизнесе.
Это и API-first-подход , при котором каждый продукт доступен через стандартизированный интерфейс, есть единая платформа данных и моделей с быстрым доступом к данным. Растет сквозная ответственность за продукт.
Чтобы объяснить, как это должно работать на практике, Дмитрий Клецких использует отсылку к LEGO. Вся система выглядит как набор независимых блоков с четкими API и SLA (гарантиями уровня сервиса), которые взаимодействуют между собой по событиям и реагируют на изменения. Блоки представляют собой законченные функциональные элементы (например, расчет кредита, проверка риска, обработка платежа). Вместо разработки монолитных продуктов, решения собираются из готовых взаимозаменяемых компонентов, которые обогащаются возможностями ИИ. Для клиента продукты остаются максимально бесшовными и внешне понятными.
Блоками управляют Product Family, объединенные вокруг ключевых бизнес-направлений, таких как розница, корпоративный сегмент или инвестиционные продукты. Семьи наделяются ответственностью за весь процесс, а вместе с ней получают ресурсы: команды, бюджеты, операционные и финансовые функции. Фактически они сами управляют затратами и развитием продукта в рамках заданных лимитов. ИИ анализирует контекст и подбирает оптимальные решения для каждого этапа.
С такой архитектурой сквозных End-To-End-процессов управления продуктами и ИИ-агентами банк сможет достичь целей AI-революции. Но потребуется пересмотреть структуру команд, зоны ответственности и взаимодействие между бизнесом и ИТ. То есть речь идет не просто о внедрении ИИ, а о полном переосмыслении того, как устроена организация.
