Last Updated on 2020-12-23 by admin

Банки давно готовы к внедрению хранилищ данных (ХД), но не у каждого банка есть возможность реализовывать на базе хранилища набор сложнейших форм ЦБ РФ при условии поступления частых изменений от регулятора. Многие банки до сих пор продолжают строить отчетность на базе АБС, а далее дорабатывают ее в полуручном режиме средствами MS Excel.

В чем нуждаются банки в этой части? В Системе подготовки регуляторной отчетности (СПО), желательно с набором готовых дистрибутивных форм ЦБ РФ, с готовыми детализациями и расшифровками, с документацией, в полном соответствии с законодательством. При этом на внедрение отводится не так уж много времени и небольшой бюджет. Чаще всего хранилище данных в банке к этому моменту уже существует (в разной стадии наполненности), однако регуляторная отчетность на нем не строится. По нашему опыту последних пяти тендеров по направлению построения регуляторной отчетности можем сказать, что у четырех клиентов из пяти уже было свое ХД. Но качество данных в существующем хранилище не ясно, и бывает, что остается таковым до самого начала проекта внедрения СПО.

Рассмотрим варианты внедрения СПО

R-Style Softlab на практике сталкивалась со всеми возможными вариантами:

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

Вариант без построения хранилища данных сразу предлагаем отвергнуть. Очевидно, что сложные формы регуляторной отчетности содержат данные как минимум из 2—3 разных источников данных (например, АБС для корпоративных клиентов, АБС для розничных клиентов, MDM- или CRM-система с единым клиентом, бэк-офисная система по ценным бумагам, карточная система и т. д.). Добавим к сложности сбора данных еще и необходимость детализации сумм до самого «низкого» уровня, иногда до сделки, проводки и клиента.

Вариант 1, связанный с предоставлением ресурсов, не будем рассматривать как очевидный. Будем считать, что перед банком все-таки стоит цель внедрить специализированную Систему подготовки отчетности.

Вариант 2, предполагающий работу на «своем» ХД, когда СПО строит другая компания, не является целью рассмотрения данной статьи. Но сразу могу сказать, что такой вариант является рабочим и вполне реализуемым при грамотной организации проекта. Наша компания выполняет его в одном из банков топ-10 РФ и имеет успешный опыт организации подобных проектов.

У нас осталось два варианта — 3 и 4. Рассмотрим их подробнее.

Для проведения сравнительного анализа давайте возьмем такую ситуацию:

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

На технических аспектах реализации мы останавливаться не будем: целью этой статьи является рассмотрение только организационных моментов такого выбора. Но заинтересовавшимся техническими моментами предлагаем ознакомиться со статьей Александра Кондиайна «Как реализовать систему построения отчетности на базе стороннего хранилища данных», опубликованной в корпоративном блоге компании R-Style Softlab.

Внедрение на базе ХД банка

Плюсы: 

1. Экономия по срокам и бюджету проекта внедрения СПО, так как часть данных в ХД банка уже загружена и отлажена. Объем экономии зависит от перечня загруженных в ХД бизнес-сущностей. Где-то это может быть значительный объем годами накопленных данных, а где-то процесс построения банковского ХД только начался.
2. С точки зрения проекта по внедрению СПО вопросы по качеству данных должны быть решены на стороне ХД. Тем не менее возможны конфликты команд внедрения СПО и ХД в части зон ответственности за качество данных.
3. Работы по выгрузке данных для проекта по внедрению СПО упрощаются: один источник данных; за определение новых и измененных данных отвечает ХД банка.
4. Для Системы подготовки отчетности хранилище данных является единственным источником данных, что унифицирует процессы выгрузки-загрузки и упрощает их создание и сопровождение.

Минусы:

1. Имеющихся данных на момент начала работ по внедрению СПО может быть недостаточно. Это потребует выгрузки данных из систем-источников в Систему подготовки отчетности напрямую. При этом впоследствии потребуется переделка выгрузки для соблюдения единства архитектуры. 
2. Есть вероятность, что в рамках проекта по построению ХД не предполагается загрузка каких-то атрибутов или сущностей, необходимых для формирования отчетности.
3. Уровень детализации данных, в частности раскрытия сводных счетов, в хранилище данных может не отвечать требованиям проекта СПО. 
4. Зависимость СПО от банковского хранилища данных: согласование форматов выгрузки; изменение подходов к хранению данных в ХД; дозагрузка в ХД новых атрибутов и сущностей.
5. Двойная перегрузка (Системы-источники -> Хранилище данных -> СПО) необходимых для построения отчетности данных, что, в частности, увеличивает срок подготовки отчетов.
6. Увеличение срока внедрения СПО за счет более позднего старта работ и зависимости от наличия данных в ХД.
7. Поиск места возникновения ошибки (Источники данных – Хранилище данных – Выгрузка – Загрузка – СПО) крайне затруднен и лежит в зоне ответственности разных подразделений, а зачастую и разных компаний, никак не связанных между собой договорными отношениями с SLA. Отсюда необходимость грамотной организации процесса и назначения ответственных, особенно в период сопровождения внедренных форм.
8. Нужна профессиональная команда, обладающая знанием хранилища данных, которая могла бы организовать выгрузку информации из ХД банка в СПО. Это может быть как собственная команда банка, так и команда его привлеченного партнера (например, наша компания). Идеальный вариант, если команда хорошо знает левую часть модели данных (ХД банка) и правую часть (модель данных в СПО). Хуже, если она знакома только с одной структурой модели — «слева» или «справа». Наиболее рискованно поручать эту задачу компании, которая имеет общий опыт в ETL-процессах, но в данном конкретном банке не знает досконально ни «левой», ни «правой» частей модели данных.

Внедрение с построением специализированного ХД

Плюсы:

1. Отсутствие зависимости от хранилища данных банка. Работы можно начинать в любой момент времени.
2. Возможность поручить решение задачи СПО одному подрядчику «под ключ», возложив на него всю ответственность за качество и сроки работ.
3. Нет необходимости согласовывать порядок выгрузки и форматы с третьей стороной, более четкие границы ответственности.
4. Меньший срок получения отчетности, так как данные перегружаются один раз.
5. Снижение рисков, связанных с возможным отказом ХД.
6. Возможность учесть опыт, накопленный банковской командой внедрения хранилища данных в части выгрузки данных из учетных систем.
7. Облегчение сопровождения, особенно важно сокращение времени на поиск и исправление ошибок в отчетный период.

Минусы:

1. Возможен запрет архитектурного комитета банка на построение специализированного хранилища данных (для решения задач СПО) «рядом» с основным банковским ХД.
2. Частичное или полное (зависит от объекта) дублирование данных в ХД и СПО, дублирование качества данных и маппингов.
3. Не исключена дополнительная нагрузка на источники данных при выгрузке (при соблюдении ряда условий этот недостаток может быть устранен).
4. Потребуется дополнительная команда для сопровождения специализированного ХД.
5. Возможное пересечение по задачам бюджетов проектов.

Подводим итоги

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

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

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

В конечном итоге каждый заказчик расставляет свои «веса» и приоритеты на приведенные выше варианты плюсов и минусов. И выбор будет уникален для каждого конкретного случая.

Ну а R-Style Softlab всегда готова поделиться опытом и для одного, и для другого случая.