- 2026
Юлия Амириди, «Интерсофт Лаб»: Банки постепенно осваивают отечественные платформы для управления данными и эффективностью
Многие кредитные организации совмещают импортозамещение с модернизацией аналитической инфраструктуры на основе единого хранилища данных (ХД). Какой должна быть современная архитектура банковского ХД, как управлять сроками и расходами на его создание, и чем объясняется высокий приоритет переноса регуляторной отчетности из АБС в ХД, в интервью CNews рассказала заместитель генерального директора компании «Интерсофт Лаб» Юлия Амириди.
CNews: Расскажите, как идет процесс перехода на отечественное ПО в банковской аналитике?
Юлия Амириди: Рынок банковской аналитики переживает спад — в 2025-м количество проектов создания хранилищ данных и систем управления эффективностью сократилось вдвое. Снижение затронуло все сегменты, но особенно отразилось на замене иностранных аналитических платформ отечественными аналогами. Доля таких проектов упала с 46% в 2024-м до 18% в 2025-м.
Уже очевидно, что возможности импортозамещения, которые открылись в 2024 году, не реализовались. И это несмотря на готовность отечественного аналитического ПО. Спрос, который пошел было вверх, в начале 2025-го затормозили заокеанские обещания о снятии санкций и активность вокруг возвращения в Россию иностранных компаний. Многие восприняли эти события как намек на откат к использованию зарубежного ПО и взяли паузу. А когда стало ясно, что возврат западных вендоров — это спорная и далекая перспектива, благоприятный для замены аналитических систем момент был упущен.
Дело в том, что модернизация ХД и прикладной аналитики не требует больших бюджетов и сроков. При условии, конечно, что используется готовый отечественный софт. Довольно быстро можно получить и опыт миграции на разрешенные технологии и полезный результат. Но в отличии от АБС аналитические системы не относятся к объектам КИИ (объект критической информационной инфраструктуры), поэтому приоритет их импортозамещения ниже. Таким проектам включали зеленый свет, пока готовность отечественных версий АБС не стала приемлемой. Когда это случилось, банки перенаправили свое внимание и ресурсы на достижение технологической независимости учетных платформ. А импортозамещение управленческих и отчетных систем отложили.
Как известно, проекты миграции АБС идут непросто, сроки сдвигаются. Поэтому ждать кардинального изменения ситуации с импортозамещением банковской аналитики в 2026-м не приходится.
CNews: А что с внедрением отечественных аналитических платформ в банках?
Юлия Амириди: Здесь ситуация лучше. Банки постепенно осваивают отечественные платформы для управления данными и эффективностью. В основном они приходят на смену запрещенным электронным таблицам. Среди всех внедрений аналитического ПО таких проектов в 2025-м году — больше половины. А каждый третий проект выполнен для замены внутрибанковских разработок на специализированные отечественные системы.
Относить такие активности на счет импортозамещения не вполне корректно, хотя эту задачу они тоже решают. Скорее это инициативы в рамках аналитической цифровой трансформации банков. Они устраняют ограничения таблиц и самописных систем и выводят процессы управления данными, принятия решений и подготовки отчетности на новый качественный уровень.
CNews: Как сегмент автоматизации банковской аналитики перестроился после ухода западных поставщиков? Какие варианты выбора сегодня имеют банки?
Юлия Амириди: До 2022 года крупнейшие банки предпочитали иностранные платформы для ХД и подготовки отчетности, а крупные и средние — собственные разработки или готовый российский софт на базе зарубежных технологий.
В 2022-м иностранные поставщики ушли. Системные интеграторы, которые продвигали их решения в банки, переориентировались на заказную разработку. Теперь они рекомендуют отечественные технологии, инструментальное ПО со свободной лицензией и свои услуги по разработке и интеграции. Сегодня таких предложений очень много. Но они либо вообще не подкреплены опытом, либо этот опыт минимален и носит частный характер, либо он получен в другой отрасли. Как относиться к таким предложениям — не доверять или становиться площадкой для экспериментов — каждый банк решает сам.
Российским разработчикам аналитических платформ пришлось портировать свой софт на разрешенные технологии. Не все смогли это сделать. Поэтому количество проверенных локальных поставщиков аналитического ПО сократилось. Тем не менее, внедрения импортонезависимых ХД и прикладных модулей в банках имеются. «Интерсофт Лаб», например, в 2025 году успешно завершила в банках несколько проектов на отечественной версии платформы «Контур» на СУБД Postgres.
Кроме того, на банковском рынке появились новые отечественные аналитические системы и их поставщики. Сюда относится софт от ИТ-компаний, которые прежде не работали с финансовой отраслью, и новодел. Последний, чаще всего является разработкой бывших внедренцев иностранных систем. Функционал таких решений очень ограничен, например, только аллокацией расходов. Пока у новых решений нет релевантного опыта эксплуатации в банках, поэтому сложно дать им оценку.
Еще один важный для понимания рыночной ситуации момент: на сегодняшний день под вопросом оказалась целесообразность внутрибанковских разработок. Поскольку в Реестре российского ПО имеются отечественные аналитические платформы и хранилища данных, то Минцифры не рекомендует организациям разрабатывать их аналоги.
В итоге вариантов выбора аналитического ПО у банков стало меньше. Можно либо заказать разработку ХД и прикладной аналитики «с нуля» у системных интеграторов, либо выбрать готовую отечественную платформу для управления данными и подготовки отчетности от локального вендора.
CNews: Насколько изменились требования банков к платформам для управления данными и прикладной аналитике?
Юлия Амириди: Очень хороший вопрос. В последнее время мы часто слышим тезис о том, что архитектура финансовых ХД устарела, и что банкам нужны большие современные ХД. На самом деле, выбор архитектуры для работы с данными и выбор конкретных технологий для ХД, зависят только от задач, которые должно решать хранилище.
Если в приоритете автоматизация задач, которые требуют консолидации структурированных данных из разных внутрибанковских источников, то необходимо классическое ХД (DataWarehose) на базе реляционной СУБД и специализированные приложения. Примеры таких задач: финансовое планирование, управленческая отчетность, аллокации, расчет трансфертных доходов и расходов для финансовой службы, регуляторная отчетность для бухгалтерии, расчет трансфертных цен для казначейства и т.д.
Если требуется доступ к неструктурированным и слабоструктурированным данным из внешних источников, то надо разворачивать озеро данных (DataLake) на платформе Hadoop, настраивать статистические пакеты и сервисы машинного обучения. Тогда можно решать задачи тонкого сегментирования клиентской базы для розничного блока, прогнозировать риски, отслеживать мошеннические операции и т.п.
В обоих архитектурных подходах нет ничего нового. Реляционные ХД в российских банках внедряются больше четверти века. Практически в каждой кредитной организации есть такой опыт. Озера на основе технологий хранения и обработки больших данных с разным успехом апробируются банками. В 2025 году соотношение внедрений классических ХД и озер данных в финансовых организациях составило 88%:12%.
Важно понимать, что обе архитектуры имеют разных потребителей в банках. Более того, существует объединяющая их гибридная концепция LakeHouse — озеро-хранилище данных. К сожалению, сейчас она часто становится предметом заблуждений, ее противопоставляют классическим ХД и называют архитектурой «больших современных хранилищ данных». На самом деле это именно объединение классического ХД и озера данных, когда обе составляющие работают в связке, обмениваются данными, но остаются самодостаточными решениями.
В рамках импортозамещения многие хотят не просто избавиться от запрещенных технологий, а модернизировать ХД и создать «запас прочности» для решения сразу всех будущих задач. Это благородная цель, главное — не переусердствовать в ее достижении. Достаточно просто выбрать правильную аналитическую платформу. Такую, чтобы архитектуру можно было расширять, а сегменты модели данных и прикладную функциональность подключать соответственно потребностям.
Еще раз подчеркну, что в основе выбора оптимальной архитектуры и технологий для создания ХД должны лежать текущие потребности его заказчиков. Необходимости строить решение, когда внутренний потребитель отсутствует, нет. Раздвигать границы ХД нужно постепенно, по мере появления в банке новых заказчиков и их задач. Можно начать с регуляторного ХД, потом добавить приложения для решения задач финансовой службы, а позже развернуть озеро данных в интересах риск-департамента или службы комплаенс-контроля. А можно выбрать другой порядок. Одним словом, последовательность внедрения компонентов может быть любой, но отталкиваться надо от актуальных бизнес-задач. И тогда будут и полезный результат, и оптимальные сроки, и адекватные бюджеты.
CNews: От чего зависят сроки и расходы на создание хранилищ и озер данных?
Юлия Амириди: От готовности ПО и от опыта исполнителя.
Например, создание озера данных — это всегда индивидуальный проект, где решаемые задачи и нужные для них данные определяют реализацию. Для создания озер используют свободно-распространяемое и проприетарное инструментальное ПО. Выбор разрешенных инструментов сегодня большой. Скорее обеспечить результат сможет более опытный исполнитель.
В отличие от озера, к созданию хранилища структурированных данных существует два подхода. Первый — это заказная разработка, когда модель ХД и приложения для финансового управления и отчетности проектируются и разрабатываются в ходе проекта. Второй подход — это внедрение тиражного отраслевого ХД и приложений. В таком случае приобретаются лицензии на готовую модель данных, ХД-платформу и прикладную функциональность, которые нужно внедрить. На проекте выполняют интеграцию ХД с источниками банка, налаживают процессы загрузки данных в тиражные структуры согласно модели данных, готовые прикладные механизмы настраивают по методическим требованиям банка.
Заказная разработка всегда несет большие риски, ее результаты непредсказуемы. Аналитиком-постановщиком для реализации прикладной части решения должен стать заказчик — это большие трудозатраты и ответственность. Поскольку софт создается в первый раз, его функциональные механизмы и гибкость будут ограничены. Из-за того, что на старте исполнитель может вообще не понимать, какие задачи предстоит решить, сроки и бюджеты таких проектов, как правило, раздуты.
И наоборот: внедрение готового ПО — это страховка для банка. Тиражную аналитическую платформу заказчик может изучить до проекта. Есть возможность обратиться к действующим пользователям и получить объективный отзыв о возможностях ПО и компетенциях внедренческой компании. Заказчик будет участвовать в настройке механизмов ПО как эксперт-консультант. Опытный исполнитель всегда обоснует трудозатраты и сроки внедрения.
CNews: Какие прикладные задачи банки уже решают на основе отечественных хранилищ данных?
Юлия Амириди: Среди задач для импортонезависимых ХД сегодня лидирует подготовка регуляторной отчетности. В 2025-м она стала целью 37% проектов. Совсем немного от нее отстает автоматизация аллокации расходов. Далее в порядке убывания количества внедрений следуют подготовка управленческой отчетности, финансовое планирование и управление рисками. Фактически, отечественный софт уже получил успешный опыт использования в большинстве задач управления эффективностью и подготовки банковской отчетности.
CNews: Чем объясняется высокий приоритет автоматизации регуляторной отчетности?
Юлия Амириди: Здесь сработали сразу несколько причин, большинство из которых назрели давно. Но импульсом к переводу отчетности в ХД стало, конечно, импортозамещение.
Начну с того, что у банков накопились претензии к подготовке отчетности из АБС. У таких решений часто не хватает гибкости, чтобы поддержать специфику каждого банка, имеются сложности с поставкой обновлений и с сервисом сопровождения. Переход на отечественную версию АБС требует серьезных расходов, и многие не видят смысла платить за перенос проблемной функциональности. Да и готовность отчетных модулей в составе импортонезависимых АБС пока низкая. Не без оснований банки опасаются, что миграция АБС затянется на неопределенный срок, и привычные механизмы подготовки отчетности перестанут работать. Перевод отчетных процессов в ХД является страховкой от проблем в период модернизации АБС. Одновременно он помогает подготовить инфраструктуру кредитной организации к датацентричному сбору данных для надзора. Банк России последовательно движется в этом направлении и сбрасывать со счетов его планы по совершенствованию сбора отчетности кредитных организаций недальновидно.
CNews: Что отличает предложение «Интерсофт Лаб» для импортозамещения банковской аналитики от конкурентов?
Юлия Амириди: Пожалуй, назову три момента: готовность отечественной аналитической платформы, не имеющие аналогов в России управленческие приложения, и успешный опыт внедрения этого ПО в банках.
Отечественная версия платформы управления данными и эффективностью «Контур» была включена в Реестр российского ПО под номером 21171 в январе 2024 года. В состав платформы входит хранилище данных «Контур» на основе готовой банковской модели данных и пакет приложений для поддержки ключевых управленческих процессов и подготовки банковской отчетности. Пакет в том числе включает несколько уникальных приложений, которые после ухода с российского рынка иностранных поставщиков не имеют альтернатив, как например приложение «Трансфертное управление ресурсами». Оно предназначено для расчета трансфертных цен и трансфертных доходов и расходов. На создание текущей версии приложения потрачено более 15 лет. В разные годы приложение было внедрено в десятках банков России и СНГ. Каждый проект чем-то его обогатил. Таким серьезным опытом автоматизации расчета трансфертов не обладает ни одна российская ИТ-компания. Поэтому вряд ли у этого решения появятся отечественные аналоги даже на долгосрочном горизонте. Такие приложения являются стратегическим конкурентным преимуществом «Интерсофт Лаб».
Платформа «Контур» уже прошла проверку практикой на технологическую независимость. За два года в российских банках на ее основе введены в промышленную эксплуатацию регуляторные хранилища данных, решения для подготовки управленческой отчетности и аллокации расходов. В реализации проекты автоматизации бюджетирования, трансфертного управления ресурсами и подготовки риск-отчетности. Это отличные результаты, особенно с учетом ситуации на рынке банковской аналитики.
Автор: Юлия Амириди, заместитель генерального директора компании «Интерсофт Лаб»
Источник: CNews