Как снизить риски внедрения хранилища данных на отечественной платформе

Каковы основные риски создания в банках импортонезависимых хранилищ данных и как их предотвратить? Рассказывает Юлия Амириди, заместитель генерального директора компании «Интерсофт Лаб».

Двухлетняя пауза в автоматизации банковской аналитики подошла к концу. Банки возвращаются к отложенным проектам создания хранилищ данных и инициируют новые для оптимизации аналитической инфраструктуры в рамках импортозамещения. В приоритете — отечественные ХД-платформы на основе разрешенных технологических компонентов.

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

Создание импортонезависимого ХД требует пристального изучения «традиционных» и присущих локализации рисков и выработки способов их минимизации.

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

Самостоятельное создание импортонезависимого ХД

Разрабатывать ХД на независимой СУБД своими силами или приобрести готовый аналитический пакет? Дилемма, которая встает почти в каждом проекте.

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

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

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

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

Превращение ХД в инфраструктурный проект

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

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

Чем это грозит? Во-первых, неприятием его результатов со стороны пользователей внутри банка. Во-вторых, превращением ХД в оперативный склад данных.

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

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

Неготовность отечественных ХД и приложений

Оценка готовности отечественных версий тиражного аналитического ПО становится серьезной задачей. Формально в Реестре российского ПО для ЭВМ и БД зарегистрированы всего 3-4 готовых отраслевых пакета для создания финансовых хранилищ данных и решения на их основе прикладных задач кредитных организаций. При этом в тендерах на внедрение импортонезависимых ХД в банках участвует гораздо больше ИТ-компаний.

Что предлагают все эти поставщики? Зачем участвуют в конкурсах? И чем грозит банку выбор несуществующего ПО?

Скажем прямо, портация тиражного ХД на разрешенную СУБД — задача недешевая и небыстрая. Не все поставщики готовы выполнить её за свой счет. Многие ИТ-компании пытаются переложить затраты на портацию на своих заказчиков, пряча их в бюджеты проектов.

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

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

Чтобы снизить риски выбора аналитической платформы, не отвечающей критериям отечественного ПО, начать следует с проверки её регистрации в Реестре Минцифры. Но полную гарантию готовности российского софта к внедрению даст только пилотный проект. Потратьте 4–6 месяцев, чтобы развернуть на выбранной платформе хранилище данных и решить небольшую прикладную задачу из скоупа проекта. Вы сможете объективно оценить наличие и качество отечественного ХД, компетенции внедренческой команды и ее готовность соблюдать взятые на себя обязательства.

Высокие эксплуатационные требования к ХД

Размеры банковских ХД могут быть очень впечатляющими и достигать 200 ТБ и более. Готовы ли ХД на отечественных СУБД адаптироваться к таким объемам? Этот вопрос откровенно беспокоит владельцев больших ХД при разработке планов импортозамещения.

Безусловно, такие объемы данных представляют серьезную нагрузку для любой СУБД. Для работы с ними правильнее использовать распределенную архитектуру. Отечественные СУБД предлагают необходимые для этого технологии и расширения, например Shardman для СУБД Postgres Pro. Правда, шардирование требует серьезного перепроектирования ПО. Стоит ли прибегать к нему в тиражной версии аналитической платформы, наращивая стоимость и самой платформы и СУБД? На наш взгляд, в этом нет необходимости. Разумнее рассматривать эту опцию как заказную в исключительных случаях.

В нашей практике, насчитывающей десятки ХД-проектов, хранилища ни разу не достигали 200 ТБ даже в банках из топ-10, где решались задачи сбора основных портфелей данных и подготовки регуляторной и управленческой отчетности.

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

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

Автор: Юлия Амириди, заместитель генерального директора компании «Интерсофт Лаб»

Источник: CNews