Импортозамещение без боли: как банку перевести аналитику на разрешенные технологии
«Импортозамещайте, только не мешайте нам работать» - ставят ультиматум своим ИТ-службам банковские финансисты. О том, как кредитной организации перевести аналитическую платформу на отечественные технологии без рисков для управления, рассказывает Юлия Амириди, заместитель генерального директора компании «Интерсофт Лаб».
По мере погружения в тему перехода на отечественный софт у кредитных организаций наступает прозрение: в большинстве случаев импортозамещение прикладных банковских систем предполагает не миграцию, а перевнедрение. Огромные расходы, большие сроки и серьезное отвлечение внутренних ресурсов – это только одна половина проблемы перевнедрения. Другая – в том, что риски внедрения новой системы намного выше, чем при плановой миграции ПО. Особенно, если система разрабатывается с нуля в ходе проекта импортозамещения.
Увы, для АБС перевнедрения не избежать. Но, если банк использует тиражное аналитическое ПО российской разработки – хранилище данных, систему управленческой отчетности, модуль аллокации расходов и прочие решения, повторного внедрения может не потребоваться.
Тиражный софт существует не просто так, и готовое аналитическое ПО отлично проявляет себя в решении задачи импортозамещения. При этом его зрелость напрямую влияет на сложность, трудоемкость и продолжительность переноса привычной бизнес-логики заказчика на разрешенный технологический стек.
Если спросить у пользователей управленческой системы, как они представляют себе результаты её «оботечествления», в ответ прозвучит, что надо просто «вынуть» иностранную СУБД и заменить ее на разрешенную без изменения функциональности и настроенных процессов бюджетирования, подготовки внутренней отчетности или расчета трансфертных цен. И такой сценарий действительно исполним при переводе на независимые технологии зрелого тиражного ПО.
В чем отличия миграции и внедрения
В общем случае подходы к импортозамещению аналитического ПО сводятся к двум вариантам.
Первый вариант – миграция, то есть перенос настроек программного продукта и накопленных данных на отечественную платформу того же вендора с идентичной функциональностью. Это техническая задача, которая обычно не меняет для конечного пользователя устоявшихся бизнес-процессов и привычек. Он работает по сложившимся правилам и в знакомых интерфейсах. Главное ограничение реализации первого варианта – готовность разрешенной версии ПО.
Второй вариант – внедрение отечественной аналитической платформы другого разработчика взамен запрещенного ПО. Он оправдан, когда миграция по каким-то причинам невозможна. Как правило, в таких случаях заказчики хотят повторить в новой системе наработанные подходы. Но это практически нереально. Отличия тиражных платформ разных поставщиков не позволяют воспроизводить в них управленческие процессы один в один, хотя вполне возможно сохранить весь нужный инструментарий и даже улучшить принятые практики. А вот в случае заказной разработки аналитического ПО ИТ-поддержка сложившихся технологий наверняка пострадает. Потому что софт, разработанный впервые, всегда уступает по своему качеству и возможностям программным продуктам, которые вобрали в себя опыт многих проектов.
Для перевнедрения, а тем более для разработки нового ПО надо выполнить несколько критически важных этапов, в которых не нуждается проект миграции (и это существенно снижает его стоимость, что является безусловным плюсом миграции). Как минимум, необходимо зафиксировать бизнес-требования и согласовать с заказчиком техническое задание на их реализацию. На этих этапах закладывается фундамент успешного проекта, поэтому принципиально важны компетенции исполнителя. Неопытный, без знания предметной области или отраслевой специфики аналитик может неверно законспектировать, пропустить или исказить критически важные требования. Допущенные в результате ошибки в архитектуре, в доработках или в настройках ПО могут проявиться на поздних этапах проекта или уже в эксплуатации и дорого обойтись заказчику.
Проект миграции опирается на уже сложившиеся бизнес-требования, и его границы заданы эксплуатируемым в банке функционалом. От исполнителя требуется только перенести работающее по понятным алгоритмам решение на обновленную аналитическую платформу, а от заказчика – протестировать и подтвердить корректность обработки данных и выпуска отчетности.
Как происходит миграция управленческой системы
Практически всем банкам-пользователям аналитического ПО российской разработки, которое опирается на иностранные технологические компоненты, рано или поздно придется выбирать между миграцией и перевнедрением.
На примере платформы управления банковской эффективностью «Контур» от компании «Интерсофт Лаб» (включена в Реестр российского ПО под номером 21171) рассмотрим, как происходит процесс миграции, и что получает заказчик такого проекта.
Представьте: сегодня финансисты выпускают управленческую отчетность из хранилища данных на СУБД Oracle, а завтра у них на рабочем столе появляется еще один ярлык для запуска такой же системы, но на СУБД Postgres. Внешне для пользователей ничего не меняется. И, главное, цифры в одинаковых отчетах, выпущенных за контрольный период из обеих систем по идентичной методике, совпадают.
Возможно ли такое в принципе? Да, вполне. Но есть несколько условий, соблюдение которых обязательно: использование зрелого аналитического ПО, миграция на его готовую версию из Реестра российского ПО, выбор правильных критериев приемки результатов.
Как известно, архитектура зрелого ПО предполагает распределение обработки данных по слоям. Слои и компоненты внутри них независимы и взаимодействуют через интерфейсы. Использование многослойной архитектуры позволяет заменять, модернизировать или масштабировать отдельные части ПО без изменения остальных. При таком подходе портация ПО на отечественные технологии (прежде всего, замена СУБД и переход на новые диалекты SQL) требует разумных усилий и не дестабилизирует остальные части системы. В этом его главное преимущество перед монолитной архитектурой, характерной для незрелых решений с ограниченным опытом внедрения и эксплуатации.
Информационно-аналитическая платформа «Контур» развивается с 1999 года. Она включает хранилище данных на основе банковской модели и широкий набор приложений для управления прибыльностью и рисками финансовых организаций. За 25+ лет платформа внедрена в десятках банков России и стран СНГ. Это софт высокой степени зрелости с классической многослойной архитектурой.
В 2023 году в рамках внутреннего проекта вендора платформа была портирована на СУБД PostgreSQL/Postres Pro. Для этого разработчики переработали более 200 МБ программного кода и настроек СУБД, адаптировали запросы и оптимизировали индексы для быстрой работы. Поскольку вся логика обработки данных сосредоточена на стороне базы данных, миграцию приложений удалось максимально упростить. Как следствие, они сохранили привычные для пользователей инструменты и интерфейсы. В результате была создана отечественная версия тиражной платформы «Контур», которая отвечает ожиданиям пользователей импортозамещающего аналитического ПО в части функциональных возможностей, производительности и эргономической преемственности.
Благодаря этому миграция на отечественную версию платформы «Контур» стала понятной задачей с прогнозируемыми сроками и результатами. Ее решение включает несколько этапов с прозрачными критериями приемки:
- Разворачивание пользовательской конфигурации готовых тиражных компонентов на СУБД Postgres на аппаратном обеспечении заказчика.
- Интеграция хранилища данных на Postgres с системами-источниками банка для перенаправления потоков первичных данных в новую управленческую систему без изменения их состава. Условием приемки результатов является совпадение данных в источниках и в тестовой версии отечественного хранилища.
- Перенос кастомных расширений, содержимого справочников и настроек управленческих приложений для сохранения действующих правил ИТ-поддержки управленческих процессов и подготовки внутренней отчетности банка на новой отечественной платформе. Критерием приемки является совпадение или объяснимое принятое заказчиком расхождение в управленческих показателях, вычисляемых за тестовый период в «старой» и «новой» системах.
- Опытно-промышленная эксплуатация продолжительностью от одного до трех месяцев с целью проверки непрерывности управленческих процессов при переходе к эксплуатации импортонезависимой аналитической платформы.
Все перечисленные задачи выполняются при минимальном участии специалистов банка. Фактически, роль пользователя в проекте миграции на отечественную версию платформы «Контур» сводится к сверке управленческих отчетов и показателей, выпущенных из систем на СУБД Oracle и на СУБД Postgres.
Именно так с точки зрения банковских финансистов должен выглядеть идеальный проект импортозамещения аналитического ПО. Приятным бонусом к его результатам станет скидка на поставку лицензии для отечественной версии платформы «Контур», поскольку для миграции действует система апгрейд.
