Продуктовая фабрика: централизованная платформа управления продуктами для банков

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

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

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

- централизует продуктовую логику;

- ускоряет запуск изменений;

- интегрируется с существующими системами без жёсткой привязки к чужому стеку;

- снимает проблемы vendor-lock.

Мы разработали Продуктовую фабрику — микро-сервисную платформу, которая упрощает работу с теми механиками, которые должны меняться быстро: продукты, тарифы, параметры, атрибуты, правила и логику расчётов. При этом АБС остаётся главной книгой и является мастер-системой по ведению счетов и проводок между счетами клиентов. Такой подход позволяет элегантно встраиваться в существующую экосистему банка и эволюционно мигрировать продукты на новую платформу, снимая нагрузку с АБС и вынося в новую платформу только нужные сценарии.

Продуктовая фабрика построена вокруг основных модулей.

Конструктор продуктов — модуль, в котором банк собирает продукт/тариф из атрибутов и бизнес-правил. Именно здесь продуктовая команда или аналитик может описать, как работает продукт/тариф, при каких условиях применяется ставка, как меняется комиссия и какие параметры должны попасть в цифровые каналы.

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

Billing/движок расчётов — модуль, который исполняет правила: принимает запрос из цифрового канала или внутренней системы, определяет нужный продукт, подтягивает условия из конструктора, данные из витрины и возвращает рассчитанное значение. Например, комиссию, процентную ставку или баллы лояльности.

Внутри платформы модель продукта строится на двух уровнях: 

Первый — шаблон продукта: структура будущего тарифа, вклада, карты, зарплатного проекта или иного вида продукта и услуги. 

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

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

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

Второе — low-code-подход. Управлять продуктом можно через интерфейс без участия разработчика: менять тарифы, параметры, условия и другие настройки. Например, аналитик может за минуту изменить комиссию за перевод с 500 до 600 рублей, после чего новое значение синхронно применяется во всех подключенных системах.

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

- АБС остаётся главной системой учёта.

- Продуктовая фабрика забирает на себя продуктовую логику, тарифы, описания и расчёты. 

Такой подход позволяет выносить продукты на платформу постепенно: сначала один, потом второй, затем тарифы для отдельных сегментов.

Следующим шагом мы заложили микро-сервисную архитектуру. Это было важно и для внутренней разработки, и для будущих клиентов. Модули можно развивать параллельно, не ломая соседние части системы. Клиент может пилотировать только часть платформы. А сама система не превращается в тяжёлый монолит, который сложно масштабировать и дорого интегрировать. Даже если банк пока не готов подключать витрину данных или расчётный модуль, он уже может использовать конструктор продуктов как самостоятельный инструмент.

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

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

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

Для работы со сложными расчётами в продукте мы предусмотрели отдельный test-tool — инструмент, который помогает быстро проверять, как сработает то или иное правило ещё до вывода в рабочий контур. Это особенно важно для банковских продуктов, где правила могут быть многоступенчатыми, зависеть сразу от большого количества входных данных и влиять на итоговые тарифы, комиссии и условия обслуживания.

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

Правило описывается на языке FEEL и включает входные данные, логику обработки и выходные значения. Test-tool позволяет быстро проверить правило на конкретном наборе входных данных без сохранения сценария, а при необходимости — создать и сохранить тест-кейсы для повторного использования. В каждом тест-кейсе задаются входные параметры и ожидаемый результат, после чего система выполняет правило, получает фактический результат и сравнивает его с ожидаемым. 

Банк также может запускать набор таких проверок по разным сценариям — например, по всем ключевым вариантам расчёта комиссии, ставки или бонуса. Результат отображается в понятном виде: какие сценарии отработали корректно, где есть отклонения и в каком именно месте расчёт пошёл не так.

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

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

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

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

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

Одна из сильных сторон платформы — технологическая независимость. Мы проектировали её не как коробочный сервис с сильной зависимостью от решений вендора, а как продукт, который может встроиться в уже существующий ландшафт компании. Если в компании уже внедрены Postgres Pro, vanilla Postgres или другой совместимый компонент, мы не заставляем менять инфраструктуру только ради внедрения нашей платформы. То же касается и АБС: платформа не требует установки какого-то специфичного решения и может интегрироваться с той системой, которую банк уже использует. Такой подход делает решение понятнее для ИТ-команд, снижает барьер на старте проекта и позволяет быстрее запускать изменения без долгого ожидания ответов о технической возможности доработок.

Конструктор продуктов как единая точка управления тарифами и условиями

Конструктор продуктов — это единая точка, где банк настраивает тарифы, условия и параметры продукта. Вместо логики, разбросанной по АБС, мобильному банку, сайту и внутренним системам, всё собирается в одном интерфейсе. 

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

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

Кастомизация продуктов и услуг под конкретного клиента

Продуктовая фабрика позволяет не только управлять стандартной линейкой, но и гибко кастомизировать продукты и услуги под конкретные запросы клиента. Для этого банк настраивает бизнес-правила, которые при разных входных параметрах определяют, какие продукты, тарифы и условия доступны клиенту и с какими свойствами. Здесь работают сразу несколько модулей платформы: конструктор задаёт логику продукта, витрина данных подтягивает профиль клиента и его атрибуты, а движок расчётов возвращает готовый результат. Банк может объединять разные продукты в пакеты услуг для своих клиентов.

На стороне клиента это может выглядеть просто: в интерфейсе ДБО пользователь выбирает нужные параметры, двигает ползунки и сразу видит рассчитанный результат с учётом своего профиля — например, остатков, переводов, пополнений или снятий. Для банка это важная точка роста: можно предлагать более точные продуктовые условия клиентам с нестандартными запросами, которые не попадают в стандартную тарифную линейку, и тем самым увеличивать дополнительные продажи.

Интеграция с цифровыми каналами банка

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

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

Аналитика на основе визуально наглядных дашбордов

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

Через единый интерфейс можно отслеживать разные продуктовые направления, управлять изменениями и анализировать, как новые настройки влияют на ключевые показатели — например, скорость запуска продуктов, доходность, клиентскую активность или конверсию. Дополнительно это упрощает аудит изменений и делает управление продуктовой линейкой более прозрачным для бизнеса и ИТ-команд.

Автоматизация зарплатных ведомостей

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

В результате процесс стал заметно быстрее и прозрачнее: среднее время обработки сократилось в 3 раза, а отзыв ошибочной ведомости — в 10 раз. Поскольку сценарий стал почти полностью автоматизированным и больше не требует постоянных ручных вмешательств, банк смог расширить окно обработки ещё на 2 часа. Это особенно важно для регионов с более ранними часовыми поясами: у клиентов появилось больше удобного времени для работы с ведомостями по московскому времени. При этом банк может обрабатывать больше ведомостей в течение дня без пропорционального роста ручной нагрузки на сотрудников.

Универсальный зарплатный проект

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

Умный накопительный счёт с динамической логикой

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

В мобильном приложении удобство такого счёта видно сразу: продукт становится понятным и «живым», потому что клиент видит, как его действия влияют на доходность. Для банка это тоже выгодно: такая механика повышает привлекательность счёта и стимулирует транзакционную активность. Получается win-win-функциональность: клиент получает более прозрачную и потенциально более выгодную модель накопления, а банк — рост вовлечённости и использования карт.

Результат внедрения: банк существенно нарастил портфель, транзакционная активность выросла на 25%, а 30% ранее неактивных клиентов начали чаще совершать покупки. Новый НС занял 22% в структуре накопительных счетов, а число клиентов, использующих продукт, только за первые 2 месяца после запуска проник в 5% от активной клиентской базы показав высочайшую конверсию, в последующие месяцы активно наращивая базу

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

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

Платформа уже дала измеримый эффект в реальных сценариях наших клиентов.

В зарплатных проектах:

- полностью автоматизированы зарплатные ведомости;

- время обработки ведомостей сократилось в 3 раза;

- отзыв ошибочно направленной ведомости сократился в 10 раз.

В кейсе с новым накопительным счётом получились такие результаты:

- портфель нового НС занял 22% в структуре накопительных счетов;

- число клиентов, использующих новый НС, превысило 10% от активной клиентской базы;

- общее число клиентов с накопительными счетами превысило 25% от активной клиентской базы.

Отдельно изменились поведенческие метрики:

- транзакционная активность клиентов, открывших новый НС, выросла на 25%;

- 30% клиентов, которые раньше не проводили транзакции, начали совершать покупки после открытия нового НС;

- по когорте клиентов, открывших счёт в сентябре, удержание после первых двух месяцев составило 95%.

Но главный результат — системный. Продуктовая фабрика может стать для банка отдельным слоем управления продуктами: снять часть нагрузки с АБС, сократить стоимость изменений, ускорить запуск новых предложений, уменьшить риск рассинхронизации между каналами и дать банку более предсказуемый способ развивать продуктовую линейку.