Что нужно знать про внедрение хранилища данных

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

В последнее десятилетие хайп вокруг решений для больших данных стал необоснованно заслонять хранилища данных. Иностранные вендоры и их локальные партнеры вовсю использовали конъюнктурные колебания, чтобы продать свои продукты и услуги, не заботясь о реальных потребностях банков. После ухода из России глобальных ИТ-компаний маркетинговая пена осела. Стало очевидно, что решения для больших данных не являются заменой хранилищам. Эти технологии кардинально отличаются и имеют разное назначение. Если банку требуются доступные и качественные структурированные данные для поддержки корпоративных решений и подготовки отчетности, ему нужно ХД. Когда необходима недорогая технология хранения больших объемов данных в неструктурированной форме — поможет big data.

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

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

1. ХД-проекту нужны бизнес-основания

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

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

Лучше не торопиться и дождаться мотивированного бизнес-запроса.

2. Импортозамещение не является бизнес-целью ХД-проекта

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

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

3. На запуск ХД достаточно 3-4 месяцев

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

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

4. Пилот нужен, чтобы проверить осуществимость ХД-проекта

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

В рамках пилота на выбранной платформе выполняется тестовая задача, отражающая специфику использования ХД в банке на горизонте 3-4 лет. Задача выбирается так, чтобы реализация пилота включала все этапы внедрения целевого решения и занимала не более 6 месяцев. Например, для регуляторного ХД в рамках пилотной стадии можно автоматизировать выпуск 1-2 форм обязательной отчетности, которые готовятся на основе ограниченного набора первичных данных. Это позволит проверить реализацию полного цикла подготовки отчетности — загрузку данных из учетных систем в ХД, настройку и выпуск форм, и их выгрузку в ПК «Дельта» Банка России.

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

5. Тестовое внедрение выполняется на особых условиях

Иногда пилотное внедрение путают с настройкой макета, которая может выполняться в рамках подготовки к продаже. Это разные задачи и условия их реализации отличаются. Цель макетирования — настроить небольшую часть бизнес-процесса, чтобы показать, как работает конкретный дистрибутивный механизм. Трудозатраты на подготовку макета обычно ограничивают несколькими днями. Иногда настройку выполняют прямо на глазах заказчика. Исполнитель демонстрирует макет на своих мощностях и имеющихся у него данных.

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

Если выбранный вендор не приветствует пилотирование или не готов соблюдать обычаи делового оборота, скорее всего он пытается продать воздух вместо ПО и компетенций.

6. Интеграция необходима для достижения бизнес-целей

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

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

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

7. Интеграционный проект всегда индивидуален

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

8. Прикладные решения нуждаются в адаптации

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

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

9. Совместное развитие ХД требует договоренности сторон

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

Все варианты и возможности развития и расширения ХД лучше уточнять до старта ХД-проекта.

10. Каждая прикладная задача увеличивает отдачу от инвестиций в ХД

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