Почему переход на новую АБС занимает не полгода, а год

Причина 1. Банк не сразу понимает, какие данные нужно переносить

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

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

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

• какие данные переносить в рабочий контур новой АБС;
• что оставить в архиве;
• какие записи нужно очистить или объединить;
• как обработать дубли клиентов и договоров;
• какие справочники стали устаревшими;
• какие данные нужны для отчетности и регуляторных проверок;
• кто на стороне банка подтверждает корректность выгрузки и загрузки.

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

Если в банке уже есть отдельный контур качества и консолидации данных, подготовка проходит быстрее. Для таких задач у Финист есть решения в направлении корпоративного хранилища данных банка.

Причина 2. Старые процессы не всегда переносятся в новую архитектуру

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

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

Например, при переходе могут потребоваться решения по таким вопросам:

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

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

Причина 3. Самая сложная часть часто находится вокруг АБС

Ни один современный банк не работает только в одной системе. АБС должна обмениваться данными с ДБО, CRM, фронт-офисом, платежными сервисами, скорингом, риск-модулями, хранилищем данных, отчетностью, государственными сервисами, системами ПОД/ФТ, ФССП, ФНС и внутренними витринами данных.

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

В зоне интеграций обычно проверяют:

• обмен с ДБО для физических лиц и другими дистанционными каналами;
• связь с CRM и клиентским контуром;
• передачу данных в отчетность и хранилища;
• взаимодействие с модулем ФССП;
• процессы ПОД/ФТ и AML;
• интеграции с платежной инфраструктурой;
• обмен с государственными и внешними сервисами;
• сценарии отказов, повторной отправки и сверки данных.

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

Причина 4. Приемочное тестирование нельзя заменить короткой проверкой

Желание быстрее выйти в промышленную эксплуатацию понятно. Но сокращение тестирования почти всегда переносит риски из проектной команды в операционный день банка.

При переходе на новую АБС важно проверить не только отдельные функции, но и сквозные сценарии:

• открытие и ведение счетов;
• проведение платежей;
• работу с кредитами и депозитами;
• закрытие операционного дня;
• формирование проводок;
• обмен с ДБО и внешними системами;
• подготовку отчетности;
• права доступа и роли пользователей;
• обработку ошибок и отклоненных операций;
• корректность архивных и исторических данных.

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

Поэтому полноценная приемка — это не бюрократия и не потеря времени. Это способ убедиться, что новая АБС выдержит реальный операционный день банка.

Причина 5. Сотрудники тоже должны перейти на новую систему

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

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

Более устойчивый сценарий — начинать обучение заранее:

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

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

Что объединяет успешные проекты перехода на новую АБС

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

Банки, которые заранее проводят подготовку, проходят проект спокойнее. Они не пытаются решить все вопросы в последние недели, а постепенно закрывают ключевые зоны риска:

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

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

Почему планирование важнее обещания «быстрого запуска»

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

Поэтому корректный проект начинается до первой настройки системы. На подготовительном этапе банк должен ответить на несколько вопросов:

• какие бизнес-цели должен решить переход;
• какие ограничения есть в текущей АБС;
• какие процессы нужно сохранить, а какие изменить;
• какие интеграции критичны для запуска;
• какие данные должны быть очищены до миграции;
• какие подразделения участвуют в приемке;
• какие критерии означают готовность к промышленной эксплуатации.

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

Как Финист помогает снижать риски перехода

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

Команда Финист помогает банкам пройти ключевые этапы перехода:

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

Для банков, которые рассматривают переход на отечественный технологический стек, полезен также материал Как выбрать верный путь при миграции АБС на отечественные СУБД.

Вывод

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

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

Обсудить переход на новую АБС и этапы проекта можно через страницу Внедрение или продуктовую страницу Автоматизированная банковская система Финист-АБС.