ПО для автоматизации банка: когда нужна разработка на заказ?

ПО для автоматизации банка: когда нужна разработка на заказ?

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

Как устроен ИТ-ландшафт банка

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

Для каждой ситуации банк выбирает оптимальный вариант из трех базовых подходов:

  • Готовое программное обеспечение
  • Собственная разработка
  • Разработка на заказ

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

Какие у банков задачи по цифровизации

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

Актуальные задачи банков затрагивают несколько направлений:

  • Импортозамещение

После ухода иностранных вендоров и интеграторов с российского рынка их продуктам и услугам требуется найти замену. Отдельные системы, которые используются для обработки транзакций и хранения финансовой информации, признаны объектами критической информационной инфраструктуры. Для них на законодательном уровне установлен срок замены — 1 января 2028 года (но он может быть продлен до 2030 года).

  • Модернизация

ИТ-экосистемы, которые создавались 20–30 лет назад, стали слишком тяжеловесными и скорее ограничивают, чем помогают в развитии. Например, если процесс одобрения кредита требует слишком большого количества ручных проверок, то у банка будет ограничение по количеству заявок, которое физически возможно обработать. Обход этого ограничения открывает новые возможности для роста.

  • Цифровая трансформация

Банки активно осваивают современные технологии, в частности, искусственный интеллект. ИИ трансформирует работу пользователей, забирает на себя рутинные задачи, позволяя сфокусироваться на том, что действительно важно. Ассоциация Финтех отмечает, что ИИ используют уже 50% игроков. Цифровая трансформация затрагивает и другие направления: платежные сервисы, гиперперсонализация клиентского опыта, банкинг вещей, API-интеграции с партнерскими экосистемами и т. д.

Какие процессы в банке нужно автоматизировать

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

ИТ-экосистема российского банка в 2026 году

Основные информационные системы банка:

  • Автоматизированная банковская система (АБС) — ядро банка, центральная система, через которую проходят все операции: управление счетами и вкладами, обработка транзакций, кредитные и депозитные операции, операции по картам.
  • Рабочее место сотрудника — единое окно, которое обеспечивает операционистам и менеджерам быстрый доступ к функциональности различных систем, а также просмотр информации о клиентах в удобном формате.
  • Модули по различным продуктам банка — кредитный конвейер, управление депозитами, валютные операции, факторинг, онбординг клиентов и т. д.
  • Дистанционное банковское обслуживание — интернет-банкинг и мобильные приложения для взаимодействия клиентов с банком.
  • Контакт-центр и CRM — сервисы для управления коммуникациями с клиентами на стороне банка, включая цифровизацию воронки продаж, управление маркетинговыми активностям, звонки и отправку сообщений.
  • Системы POS и ATM — сервисы для обработки информации, поступающей через терминалы и банкоматы.
  • Системы информационной безопасности — набор систем для управления рисками, скоринга, проверок контрагентов, мониторинга, расследования инцидентов и т. д.
  • Корпоративные информационные системы — поддерживающее ПО, которое обеспечивает работу банка как организации: электронный документооборот, бухгалтерия, закупки, казначейство, кадры, аналитика и многое другое.
  • Инфраструктурное ПО — ПО, которое связывает воедино всю ИТ-экосистему банка: система управления мастер-данными, система нормативно-справочной информации, система авторизации и аутентификации, система управления учетными записями, интеграционные сервисы.

Посмотрите пример замены legacy-системы в крупном банке с помощью Jmix

Как лучше реализовать ПО для автоматизации в банке — внедрить «коробку», разработать своими силами или обратиться к технологическому партнеру? Универсального алгоритма не существует, однако общие паттерны все-таки можно выделить.

Когда банку выгоднее использовать готовое решение

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

Такой подход характерен для решений с понятной функциональностью и различиями в деталях: АБС, СЭД, CRM, учетные системы, сервисы для управления пользовательскими учетными записями и т. д.

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

Готовые системы предлагают набор процессов, которые можно адаптировать к пользовательским сценариям конкретного банка. Например, в одном из продуктов Хоулмонт, СЭД ТЕЗИС, настройки реализованы в виде Low-Code конструктора. За счет этого можно автоматизировать не только непосредственно работу с документами, но и процессы, построенные вокруг нее: закупки, экспедицию, архивное хранение, проведение заседаний и т. д.

В каждом классе систем свои лидеры. Например, на рынке АБС несколько лет назад доминировали иностранные системы, но теперь баланс радикально сместился в пользу российских производителей: ЦФТ, Диасофт, R-Style Softlab.

При этом существуют исключения. Титаны рынка — Сбер, Т-Банк, Альфа-Банк, ВТБ — используют АБС собственной разработки. У Хоулмонт был проект разработки АБС для компании IT Consultores из Парагвая, которая развивает собственные продукты для банковской отрасли. IT Consultores планировала выпустить новое поколение своей флагманской АБС Finera. Проект предполагал переработку архитектуры для более удобного масштабирования и кастомизации, а также модернизацию UI. IT Consultores обратились к нам, поскольку решили отказаться от Oracle Forms и использовать в качестве технологической основы платформу Jmix. Дизайн системы, разработанный в агентстве UXDA, получил международную премию Design Talent Awards в категории сервисного дизайна. Технологии Хоулмонт сделали возможным его воплощение не только в макете, но и в реальном приложении.

Готовые продукты не подходят в трех ситуациях:

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

В этих ситуациях оставшиеся варианты — разработка собственными силами или заказная разработка.

В каких случаях банку лучше разрабатывать ПО собственными силами

Крупные банки сегодня — это технологические компании. Они содержат штат собственных архитекторов, аналитиков, разработчиков, QA, DevOps, UI-UX дизайнеров и т. д. В рейтинг ИТ-брендов работодателей по версии Хабра и ЭКОПСИ в 2025 году вошло 26 участников из финансового сектора — это примерно 20%. В рейтингах крупнейших ИТ-компаний по выручке банки также занимают заметные позиции. По данным агентства Smart Ranking, 11% рынка приходится на финтех.

Что дают банкам собственные ИТ-команды:

  • Вся разработка ведется в контуре банка, обеспечивается полный контроль над ПО
  • Внутренняя команда лучше понимает архитектуру ИТ-экосистемы банка
  • Быстрая реакция на изменения требований бизнеса за счет более тесного взаимодействия внутри структуры банка
  • Независимость от внешних подрядчиков

ИТ-подразделение банка может решать любые задачи. Однако в случае некоторых категорий ПО будет выгоднее поручить разработку, поддержку и развитие именно собственной команде:

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

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

Разработаем ПО для автоматизации банка
От ИИ-агентов до АБС

В чем преимущества разработки банковского ПО на заказ

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

  • Требуется экспертиза в определенной сфере

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

  • Партнерство с производителем инструментов разработки и технологий

Банки активно используют инструменты повышения эффективности разработки. Партнерство с производителем технологий позволит быстро познакомить внутреннюю ИТ-команду с инструментарием и параллельно решить задачи бизнеса. Партнер проведет банк по кратчайшему пути и сэкономит много времени. Пример такого варианта сотрудничества — уже упомянутый проект разработки АБС для IT Consultores. Один из наиболее показательных примеров российских банков — использование Jmix для создания архива. Обязательным требованием со стороны департамента ИБ со стороны банка было использовать инструменты, развернутые локально и выпущенные не позже февраля 2022 года. Команда Jmix не только обучила специалистов заказчика и помогла реализовать проект, но и разработала форк платформы специально для заказчика. Еще один пример — в СКБ Банк на базе Jmix реализованы проекты автоматизации проверок службы безопасности банка и разработки кредитного конвейера.

  • Быстрое увеличение команды для отдельного проекта

Заказная разработка позволяет снизить расходы на HR. Банк получает готовую команду и выполняет задачу в срок, но при этом без затрат на поиск специалистов, организацию рабочих мест и удержание. Заказная разработка особенно полезна, если после реализации проекта в будущем команда такого размера будет не нужна. В таком формате в одном из проектов мы разработали системы для скоринга, управления рисками, обработки заявок на кредиты и депозиты, проведения факторинговых платежей, а также представления информации о клиентах банка в едином окне. В результате сотрудники экономят до 20% времени. Теперь банк самостоятельно развивает и поддерживает систему.

Эти примеры показывают, что услуги разработки ПО на заказ могут быть полезны даже банкам с сильными ИТ-департаментами.

Как выбрать партнера для разработки на заказ

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

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

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

Пример сравнения технологических платформ

К примеру, платформа Jmix подходит для разработки корпоративных информационных систем, ориентированных на работу с данными, документами и процессами. Она позволяет ускорить разработку на 25%, а также сократить количество ставок в команде. Подробнее об экономике проектов на базе Jmix мы рассказывали в отдельной статье.

  1. Для знакомства с ИТ-партнером и технологиями может быть полезно разработать прототип.

На этапе выбора ИТ-партнера можно поручить реализацию прототипа компаниям из шорт-листа. Это позволит сравнить подход к решению конкретных задач, скорость работы, возможность внесения изменений, взаимодействие с командой. Вы не потратите время зря, так как прототип ляжет в основу полномасштабной системы. Хоулмонт может реализовать прототип для проверки концепции (Proof of Concept, PoC) бесплатно за 30–40 часов.

  1. Изучите примеры проектов компании в банковской области или в решении задач, похожих на ваши.

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

Заключение

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


Готовое ПОСамостоятельная разработкаЗаказная разработка
  • Автоматизация типовых процессов

  • Быстрое внедрение

  • Адаптация в границах продукта 

  • Погруженность в процессы и ИТ-экосистему

  • Накопление собственной экспертизы

  • Скорость реакции на изменения или инциденты 

  • Внешняя экспертиза

  • Погружение в технологическую платформу

  • Быстрое увеличение команды под проект

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

Предыдущая статья Следующая статья

Оставьте заявку, и мы ответим на все ваши вопросы

Обязательное поле