Поделиться
Замена хранилищ данных в банках: почему реклама перевешивает логику
Юлия Амириди, «Интерсофт Лаб»:
Переход на отечественные хранилища данных (ХД) стал приоритетной задачей для российских банков. Многим учреждениям предстоит не только избавиться от запрещённых элементов в текущих системах, но и внедрить совершенно новое хранилище. Как избежать ловушек недобросовестного маркетинга при выборе архитектуры ХД и программного обеспечения для его создания, рассказывает Юлия Амириди, заместитель генерального директора компании «Интерсофт Лаб».
До введения санкций 32% хранилищ данных, используемых в банках, работали на зарубежном ПО, а 54% — на российских платформах, но с применением запрещённых компонентов. Оставшиеся 14% решений были созданы силами самих банков, также на базе иностранных технологий.
Финансовым организациям пока не удалось добиться полной автономии своей аналитической инфраструктуры. Лишь немногие банки могут пойти по лёгкому пути — заменить только запрещённые элементы и продолжить эксплуатацию существующих ХД. Это доступно тем, кто строил свои хранилища на зрелых аналитических платформах с распределённой по слоям логикой обработки данных. В таких системах смена СУБД и переход на другие диалекты SQL требуют значительно меньше усилий, чем в случае с монолитной архитектурой ХД, характерной для собственных разработок и ПО с небольшим опытом внедрения. Поэтому большинству банков необходима полная замена хранилища и внедрение отечественного аналога.
После ухода зарубежных поставщиков не все российские разработчики сумели адаптировать свое программное обеспечение под разрешенные технологии. Те ИТ-компании, которые успешно справились с этой задачей, теперь могут предложить банкам для импортозамещения тиражируемые ХД-платформы с прикладными возможностями.
Помочь банкам в замене хранилищ данных вызываются и те ИТ-компании, у которых нет готового ПО. Они предлагают создание решения «с нуля» с использованием программного обеспечения с открытой лицензией (СПО). Проблема в том, что у таких команд часто не хватает компетенций для выполнения прикладных банковских задач на базе СПО. Чтобы избежать трудностей, сместить фокус внимания заказчика и заполучить проект любой ценой, они нередко прибегают к маркетинговым уловкам и давят на амбиции. Например, могут предложить вместо классического ХД, которое банк применяет для формирования управленческой отчетности, технологии больших данных и искусственного интеллекта с аргументом: «Зачем вам устаревшее хранилище, стройте современное решение». И если банк поддается на такие уговоры, он рискует не решить свои ключевые задачи.
Продавать, играя на самолюбии, научились уже давно. Еще Генри Форд и другие американские автомобильные магнаты, чтобы сбывать новые машины на перенасыщенном рынке, использовали рекламу для внушения владельцам еще не старых и исправно работающих автомобилей чувства неполноценности. И на рынке информационных технологий амбиции тоже служат мощным инструментом управления поведением потребителя. Чтобы не поддаться негативному влиянию агрессивного маркетинга и не потратить бюджет на перестройку ХД впустую, лучше заранее понять, для каких целей нужно использовать классическое хранилище данных, когда стоит развернуть озеро данных, а в каких случаях эффективно сочетать обе технологии. Особенно важно прояснить эти вопросы бизнес-заказчику ХД в банке. Ведь выбор архитектуры хранилища данных зависит от того, кто и для каких задач будет его эксплуатировать.
Когда стоит выбрать классическое хранилище данных
Если внутренний заказчик отечественного хранилища — финансовая служба, бухгалтерия, казначейство или другие подразделения банка, которым требуются структурированные данные из внутренних систем (АБС, CRM и т. д.), — необходимо классическое финансовое ХД на основе реляционной СУБД и специализированные отраслевые приложения. С помощью готовых решений банк сможет автоматизировать планирование, подготовку управленческой и регуляторной отчетности, распределение расходов, трансфертное управление ресурсами и прочее.
Для внедрения традиционного финансового хранилища данных можно использовать либо индивидуальную разработку, либо готовую отечественную платформу для ХД, оснащенную набором инструментов для автоматизации различных бизнес-задач. Риски, связанные с заказной разработкой, широко известны: непредсказуемость итогового результата для банка, узкие функциональные возможности и гибкость программного обеспечения, а также завышенные сроки и бюджет проекта. Вдобавок банку придется взять на себя роль аналитика и постановщика задач, тратить собственные ресурсы и в итоге отвечать за качество и адаптивность прикладного функционала, созданного разработчиком. Использование готового ПО делает процесс развертывания финансового хранилища данных понятным для заказчика. Банк может тщательно изучить его функционал до начала внедрения, а эффективность оценить на основе отзывов реальных пользователей. Сроки и стоимость подобных проектов четко оговариваются до их запуска.
На сегодняшний день в реестре российского программного обеспечения для ЭВМ и баз данных числится как минимум три финансовых ХД и одна готовая программная платформа «Контур» от российского разработчика «Интерсофт Лаб» (реестровая запись 21171). Она включает в себя отраслевое хранилище данных и комплект готовых приложений для планирования и бюджетирования, расчета финансовых результатов и формирования управленческой отчетности, распределения расходов, расчета трансфертных цен и доходов/расходов, а также подготовки регуляторной и риск-отчетности. Платформу «Контур» успешно используют десятки российских финансовых организаций разного масштаба. В ряде банков она уже работает на базе отечественного технологического стека.
Когда стоит развернуть озеро данных
Если внутреннему заказчику требуется аналитика, основанная на неструктурированных и слабоструктурированных данных из внешних источников, банку следует внедрить озеро данных, а также статистические пакеты и сервисы машинного обучения. Это позволит сотрудникам розничного блока, службы комплаенс-контроля, риск-департамента и других заинтересованных подразделений решать задачи тонкой сегментации клиентской базы, прогнозирования рисков, борьбы с мошенничеством и другие с помощью алгоритмов искусственного интеллекта на основе больших данных.
Создание озер данных и применение аналитики больших данных особенно актуально для крупных розничных банков. Такие системы разворачиваются преимущественно на базе свободно распространяемого ПО силами собственных ИТ-команд или с привлечением внешних подрядчиков.
Когда применять озеро-хранилище данных
Крупнейшие финансовые организации, работающие в розничном сегменте, также активно строят аналитическую инфраструктуру в гибридной архитектуре, которая объединяет возможности озера данных и классического хранилища данных.
В рамках данной архитектуры озеро данных накапливает и хранит структурированные, полуструктурированные и неструктурированные данные в их первоначальном («сыром») виде — как из внешних, так и из внутренних источников. Для последующей прикладной обработки в хранилище данных могут, к примеру, поступать сведения из внутренних источников и структурированные данные из озера. Либо возможна иная конфигурация потоков информации. Сочетание озера данных и ХД позволяет различным отделам банка выполнять аналитику на основе больших объёмов информации, а также готовить структурированную отчётность: управленческую, аналитическую и регуляторную.
Для оперативного внедрения хранилища данных в рамках гибридной архитектуры можно применить тиражируемое ПО с уже готовым прикладным функционалом, а для создания озера — использовать свободное программное обеспечение. Кроме того, на рынке существуют специализированные платформы на базе СПО для построения озера-хранилища данных. При их использовании разработка ХД и его прикладной части потребует создания всего «с нуля», что сопряжено с соответствующими сложностями и рисками.
■ Рекламаerid:2W5zFJNK6CHРекламодатель: ООО «Интерсофт Лаб»ИНН/ОГРН: 9715000862 / ОГРН 5147746205833Сайт: www.iso.ru
Короткая ссылка
