Зачем банку зоопарк решений? Какие системы банку действительно важны? 

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

От единой АБС к десяткам приложений

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

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

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

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

Типовой ландшафт среднего розничного банка выглядит примерно так:

• АБС — учет счетов, проводок, остатков и обязательной отчетности;
• CRM — карточка клиента, история контактов, продажи и допродажи;
• BPM-система — формирование бизнес-процессов, маршрутизация задач между подразделениями;
• кредитный конвейер — прием заявки, скоринг, андеррайтинг, выдача;
• финансовый мониторинг — проверка операций по требованиям 115-ФЗ;
• аналитическая платформа — отчетность для руководства и расчет показателей.

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

Специализация систем и разделение функций

Одна платформа редко решает все задачи, и на то есть причины помимо инерции:

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

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

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

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

Что теряет банк на переключениях между системами

• Повторный ввод данных. Паспортные сведения, адрес и контакты клиент диктует один раз, а сотрудник вносит их дважды или трижды. Это прямые минуты и источник расхождений: в одной базе клиент Иванов И. И., в другой — Иванов Иван Иванович с устаревшим адресом.
• Разрыв контекста. Переключение между приложениями стоит не только времени на загрузку. Операционист заново ищет клиента, вспоминает, на каком шаге остановился, сверяет номера договоров. Клиент в это время сидит напротив и ждет.
• Долгий ввод новичка в должность. Обучить человека одному интерфейсу проще, чем шести. Пока сотрудник не освоил все, он либо отвлекает коллег, либо ошибается. При высокой текучести во фронт-линии это постоянная статья затрат.
• Сложить эти потери несложно. Возьмем отделение, где оформляют сорок обращений в день. Если на переключения, поиск клиента и повторный ввод уходит по три минуты на обращение, отделение теряет два часа рабочего времени ежедневно. За месяц набирается около сорока часов — четверть ставки, потраченная на перенос данных между окнами. Подставьте свои цифры по числу операций и средней длительности обслуживания: порядок величины обычно оказывается неприятным сюрпризом.
• Качество данных. Расхождения между базами не остаются внутри ИТ. Клиент получает СМС на старый номер, письмо уходит по прошлому адресу, а персональное предложение формируется по устаревшему профилю. Сотрудник тратит время на разбор претензий, которых не должно было возникнуть.
• Рост числа связей. Проблему пробуют решить интеграциями «каждый с каждым». Но при десяти системах таких связок может быть до сорока пяти, и каждая требует поддержки. Обновили одну систему — проверяйте остальные. Ландшафт становится хрупким: сбой в звене посреди цепочки останавливает работу сотрудников банка в отделении.

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

Интеграционный слой и единый интерфейс

Первый шаг — заменить прямые связки «каждый с каждым» на интеграционный слой. Шина или middleware принимает запросы через единый набор API, а системы-источники подключаются к ней по одному разу. Число связей падает с десятков до единиц, а замена одного приложения перестает задевать соседние.

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

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

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

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

Единое окно решает половину задачи. Вторая половина — скорость изменений: продуктовая линейка обновляется несколько раз в год, также как и требования регулятора. 

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

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

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

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

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

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

Направление задает регуляторная рамка. Указ Президента РФ № 166 от 30 марта 2022 года запретил органам и организациям — заказчикам по 44-ФЗ закупать иностранное программное обеспечение для значимых объектов критической информационной инфраструктуры без согласования, а с 1 января 2025 года использовать такое ПО на значимых объектах КИИ нельзя. Банки относятся к субъектам КИИ по 187-ФЗ, поэтому замена зарубежных компонентов идет по всему ландшафту.

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

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

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

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