Вендор или собственная разработка — что выбрать банку

Евгений Пономарев, директор по разработке U-BSS:

— Работа с вендором для корпоративного ДБО — это более выгодный и предсказуемый путь.

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

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

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

Мы в U-BSS сменили уже пять поколений ДБО и реализовали сотни проектов — это опыт, который нельзя наработать за один год. Банку, решившему построить всё самостоятельно, пришлось бы проходить этот путь самостоятельно и с потерей денег.

А еще мы даём инструменты, снижающие риск вендорлока:

• предлагаем SDK для самостоятельной доработки;
• предоставляем опцию депонирование исходников;
• готовы к совместной разработке — команды заказчика и вендора ведут разработку параллельно, либо ресурсы сторон объединяются в единую команду.

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

Какую архитектуру выбирают для корпоративного ДБО: монолит, микросервисы или модульный подход?

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

Евгений Пономарев,  директор по разработке U-BSS:

— Важно подбирать архитектуру под задачу, а не под тренд.

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

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

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

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

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

Какие требования к заказчику и вендору определяют успех проекта?

Алексей Афонин, вице-президент по развитию U-BSS:

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

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

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

Один из последних кейсов U-BSS выстраивался именно по этой схеме: в результате система была установлена в банк и филиалы всего за полтора месяца — когда обычно требуется минимум 3-4. Не существует универсального решения. Банку важно понимать свои задачи, бюджет и стратегию развития, а не следовать моде.

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

Для этого мы заранее обсуждаем с заказчиком поддержку клиентов при запуске и миграции — с помощью ИИ-помощника, который отвечает на типовые вопросы клиентов: по первому входу, продуктам, тарифам, операциям и платежам. Он работает на базе нашей чат-платформы, но легко интегрируется с другими решениями. Вместе с ДБО внедряется база знаний и RAG, а в качестве LLM может использоваться как облачное, так и on-premise решение.

Дополнительно мы обучаем сотрудников банка работе с системой, помогаем IT- и бизнес-командам освоить продукт и сопровождаем миграцию. Наша цель — сделать переход максимально незаметным для клиентов и минимизировать нагрузку на персонал. А в качестве бонуса мы предлагаем SDK и помогаем построить центр компетенций внутри банка, чтобы он мог самостоятельно развивать систему и не зависеть от вендора — без vendor lock.

Банки, которые осознанно инвестируют в развитие ДБО, получают не только технологическое преимущество, но и доверие наиболее сложных и доходных корпоративных клиентов.

Сайт: ubssys.uz

Telegram: @ubssys

На правах рекламы