16 Июня 2026 10:00 16 Июн 2026 10:00 |

Поделиться

Импортозамещение хранилищ данных в банках: почему маркетинг побеждает здравый смысл

                                                                                                                                                                                                        

 Юлия Амириди, «Интерсофт Лаб»:

  Импортозамещение хранилищ данных (ХД) на повестке дня российских банков. Многим придется не просто заменить запрещённые компоненты в составе эксплуатируемых решений, а внедрить новое ХД. О том, как не попасть на удочку недобросовестного маркетинга при выборе архитектуры хранилища данных и ПО для его реализации, рассказывает Юлия Амириди, заместитель генерального директора компании «Интерсофт Лаб».

В досанкционный период 32% эксплуатируемых в банках хранилищ данных были развернуты на иностранном ПО и 54% — на российских платформах с опорой на запрещённые компоненты. Остальные 14% действующих решений представляли собой внутренние разработки банков также на основе зарубежных технологий.

Пока финансовым организациям не удалось обеспечить независимость своей аналитической инфраструктуры. Пойти простым путем и заменить в своих ХД только запрещенные компоненты, чтобы продолжить их использование, имеют возможность немногие банки. Фактически только те, кто использовали для создания ХД зрелые аналитические платформы, в которых логика обработки данных распределена по слоям. При таком подходе смена СУБД и переход на другие диалекты SQL требует гораздо меньших усилий, чем при использовании монолитной ХД-архитектуры, присущей индивидуальным разработкам и ПО с ограниченным опытом внедрения. Поэтому большинству требуется полная замена ХД и внедрение отечественного аналога.

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

Помочь банкам в замене ХД вызываются также ИТ-компании, у которых нет готового софта. Они предлагают разработку решения «с нуля» с применением ПО со свободной лицензией (СПО). Проблема в том, что у таких команд не всегда хватает экспертизы для реализации прикладных задач банков на СПО. Чтобы избежать сложностей, сместить целевой фокус заказчика и получить проект любой ценой, они нередко пускают в ход маркетинговые манипуляции и играют на тщеславии. Например, могут предложить вместо классического ХД, которое банк использует для подготовки управленческой отчетности, технологии больших данных и искусственного интеллекта с посылом: «Зачем вам устаревшее ХД, стройте современное.» И если банк поддается на такие доводы, то рискует не получить решения своих важнейших задач.

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

Когда предпочесть классическое хранилище данных

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

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

На текущий момент в реестре российских программ для ЭВМ и БД представлено не менее трех финансовых ХД и одна тиражная программная платформа «Контур» от отечественного разработчика «Интерсофт Лаб» (реестровая запись 21171). Она включает отраслевое хранилище данных и пакет готовых приложений для планирования и бюджетирования, расчета финансового результата и подготовки управленческой отчетности, аллокации расходов, расчета трансфертных цен и доходов/расходов, подготовки регуляторной и риск-отчетности. Платформу «Контур» успешно применяют десятки российских финансовых организаций различного масштаба. В ряде банков она уже эксплуатируется на отечественном технологическом стеке.

Когда развернуть озеро данных

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

Создание озер данных и применение аналитики больших данных актуально для крупных розничных банков. Разворачивают их преимущественно на основе свободно-распространяемого ПО силами собственных ИТ-команд или, привлекая к проекту внешних подрядчиков.

Когда использовать озеро-хранилище данных

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

При такой архитектуре в озере данных собираются и хранятся структурированные, полуструктурированные и неструктурированные данные в исходном («сыром») виде — из внешних и внутренних источников. В ХД для дальнейшей прикладной обработки могут, например, поступать данные из внутренних источников и структурированные данные из озера. Или возможна другая организация потоков данных. Симбиоз озера данных и ХД позволяет разным подразделениям банка получать аналитику на основе больших данных, а также формировать структурированную отчётность: управленческую, аналитическую и регуляторную.

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

Поделиться

Подписаться на новости Короткая ссылка