Когда банк планирует внедрение АБС, первый вопрос обычно звучит просто: сколько стоит система?
Логика понятна. Нужно сравнить предложения поставщиков, посмотреть лицензии, оценить базовый функционал, понять, какие модули входят в решение. Но именно здесь часто появляется первая ошибка: банк оценивает стоимость продукта, а не стоимость внедрения под свою реальную операционную модель.
На сайте Финист в материале о стоимости внедрения АБС эта мысль сформулирована прямо: основная часть затрат появляется не на этапе покупки, а в процессе внедрения и дальнейшей работы системы. По опыту проектов, внедрение, интеграции и доработка процессов могут формировать до 70% затрат.
То есть корректный вопрос не только в том, сколько стоит АБС как продукт. Важно понять, во сколько обойдется запуск системы именно в этом банке: с его данными, процессами, инфраструктурой, внешними связками и требованиями к дальнейшему развитию.
Из чего складывается бюджет внедрения
АБС затрагивает ключевые процессы банка: бухгалтерию, кредиты, депозиты, платежи и отчетность. Поэтому внедрение редко ограничивается установкой программы и выдачей доступа пользователям.
В бюджет обычно попадают:
- лицензии и функциональные модули;
- настройка бизнес-процессов;
- интеграции с внешними системами;
- миграция данных;
- инфраструктура;
- поддержка и развитие после запуска.
Стоимость лицензии обычно понятная и предсказуемая. Но вокруг лицензии есть зоны, где бюджет начинает меняться: как переносить данные, какие системы нужно связать между собой, насколько стандартный функционал подходит банку, какие процессы придется перестраивать и какие доработки возникнут после старта.
Поэтому первоначальная оценка часто выглядит аккуратно только на бумаге. Она считает систему, но еще не всегда считает весь путь до промышленной эксплуатации.
Почему оценка растет
Главный фактор роста бюджета, который выделяет Финист, - кастомизация. Чем больше доработок требуется под процессы банка, тем выше стоимость проекта и тем сложнее сопровождать систему в будущем.
Дополнительные затраты появляются, когда у банка много интеграций между системами, когда стандартный функционал нужно менять под внутренние правила, когда процессы корректируются уже во время внедрения или когда после запуска выясняется, что нужны новые доработки.
В такой ситуации растет не только стоимость. Увеличиваются сроки проекта и нагрузка на ИТ-команду банка. Команде приходится не просто внедрять систему, а постоянно уточнять требования, согласовывать изменения, проверять связки и поддерживать старые процессы до завершения перехода.
Отдельная ошибка - смотреть на АБС как на изолированный модуль. Если решение требует связывать десятки разрозненных компонентов, интеграции становятся отдельной большой статьей бюджета. А интеграции, как отмечает Финист, всегда дорого и долго.
Где чаще всего теряются деньги
Деньги теряются там, где в начале проекта не был описан полный контур внедрения.
Например, банк закладывает в бюджет лицензию и базовую настройку, но позже выясняет, что нужно переносить исторические данные, настраивать обмены со смежными системами, менять маршруты операций, проводить дополнительное тестирование и обучать сотрудников работе в новой логике.
Финист отдельно показывает это на проектном опыте. В кейсе РНКО «Эр-Финанс» среди обязательных этапов запуска были подготовка оборудования и разворачивание АБС, первичная настройка систем, проведение хозяйственных операций, подключение к расчетной сети Банка России, тестирование платежных сообщений с Банком России, размещение депозитов в ЦБ, обучение сотрудников и сопровождение первых операций.
В этом же кейсе отдельно отмечено выполнение задач, которые не были предусмотрены первоначальным планом. Это хороший пример того, почему стартовая оценка может не совпадать с финальной: в реальном запуске появляются требования, которые невозможно закрыть одной лицензией.
Почему слабое ТЗ особенно опасно
В материалах Финист по заказной разработке есть важная подсказка: фиксированный объем работ и фиксированный бюджет подходят для проектов с четко определенным ТЗ. Если ТЗ расплывчатое, проект почти неизбежно начинает жить в режиме уточнений: меняется объем работ, состав команды, приоритеты и сроки.
Для внедрения АБС это особенно чувствительно. Здесь недостаточно написать, что банку нужна учетная система. Нужно заранее понимать, какие процессы входят в первый запуск, какие данные переносятся, какие интеграции обязательны, какие проверки должны пройти до промышленной эксплуатации и какие функции можно оставить на следующий этап.
Если этого нет, бюджет начинает расти не потому, что поставщик внезапно "подорожал", а потому что реальный объем внедрения оказался шире первоначального описания.
Как архитектура влияет на стоимость
Финист делает акцент на том, что до 50% стоимости внедрения АБС определяется архитектурой выбранного решения. Это важный момент: банк может выбирать не только по цене лицензии, но и по тому, насколько система снизит или усилит будущие затраты.
Финист-АБС описывается как система для учета, обработки операций, ведения кредитов, депозитов и формирования отчетности. На продуктовой странице также указано, что система построена по модульному принципу, обеспечивает единое информационное пространство и централизованное управление операциями.
В материале о стоимости внедрения Финист объясняет свой подход так: вместо классической тяжелой АБС, которую нужно долго адаптировать, платформа строится как единый бэк-офис. Операции, учет и отчетность работают в одной логике, без дублирования между системами.
За счет этого банк может снизить часть расходов, которые обычно возникают на стыках: меньше разрозненных модулей, меньше ручных разрывов, меньше разработки с нуля там, где можно использовать настройку.
Что помогает контролировать бюджет
Первое - считать не только лицензию, а весь контур внедрения.
Второе - заранее разделить обязательный первый запуск и дальнейшее развитие. Финист указывает, что систему можно запускать по частям: сначала базовый контур, затем расширение. Такой подход позволяет не останавливать бизнес и не раздувать бюджет резким запуском всего сразу.
Третье - выбирать архитектуру, где многие вещи настраиваются, а не разрабатываются с нуля. На странице Финист-АБС среди возможностей архитектуры указаны конструктор сущностей, настраиваемое меню, BPM-процессы, генератор отчетов, настраиваемые интеграции, редактор форм и настраиваемые списки.
Четвертое - учитывать обучение, тестирование и сопровождение как часть проекта, а не как мелкие работы "потом". В банковском внедрении эти этапы напрямую влияют на то, сможет ли система перейти в нормальную эксплуатацию.
Какие сценарии внедрения бывают
Финист выделяет несколько вариантов.
Быстрый запуск подходит при выходе на рынок или запуске нового направления. Он позволяет в короткие сроки запустить базовые операции, но требует дальнейшего развития системы по мере роста нагрузки.
Поэтапное внедрение чаще выглядит наиболее сбалансированным вариантом для действующего банка. Сначала запускаются ключевые процессы, затем расширяется функциональность. Это помогает сохранить стабильность работы и распределить бюджет.
Полная замена системы - самый сложный сценарий. Он связан с переносом всех процессов и данных, требует значительных ресурсов, тщательной подготовки и контроля на всех этапах.
Главный вывод
Внедрение АБС - это не только покупка системы. Это изменение операционной модели банка.
Если оценивать только лицензию, бюджет почти неизбежно окажется неполным. Нужно смотреть на данные, интеграции, процессы, доработки, инфраструктуру, тестирование, обучение и поддержку после запуска.
Именно поэтому экономия достигается не за счет самой дешевой лицензии, а за счет правильной архитектуры и понятного сценария внедрения. Чем раньше банк видит полный контур проекта, тем проще управлять сроками, нагрузкой на команду и итоговой стоимостью.
Посмотрите подробнее, из чего складывается стоимость внедрения АБС и где банки чаще всего теряют деньги.