Как выбрать подход к внедрению Системы подготовки регуляторной отчетности - «Финансы» » Финансы и Банки
Создать акаунт

Как выбрать подход к внедрению Системы подготовки регуляторной отчетности - «Финансы»

25 дек 2020, 00:00
Финансы
0
0
Как выбрать подход к внедрению Системы подготовки регуляторной отчетности - «Финансы»
Как выбрать подход к внедрению Системы подготовки регуляторной отчетности - «Финансы»

статьей Александра Кондиайна «Как реализовать систему построения отчетности на базе стороннего хранилища данных», опубликованной в корпоративном блоге компании 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 всегда готова поделиться опытом и для одного, и для другого случая.


статьей Александра Кондиайна «Как реализовать систему построения отчетности на базе стороннего хранилища данных», опубликованной в корпоративном блоге компании R-Style Softlab. Внедрение на базе ХД банка Плюсы: Экономия по срокам и бюджету проекта внедрения СПО, так как часть данных в ХД банка уже загружена и отлажена. Объем экономии зависит от перечня загруженных в ХД бизнес-сущностей. Где-то это может быть значительный объем годами накопленных данных, а где-то процесс построения банковского ХД только начался. С точки зрения проекта по внедрению СПО вопросы по качеству данных должны быть решены на стороне ХД. Тем не менее возможны конфликты команд внедрения СПО и ХД в части зон ответственности за качество данных. Работы по выгрузке данных для проекта по внедрению СПО упрощаются: один источник данных; за определение новых и измененных данных отвечает ХД банка. Для Системы подготовки отчетности хранилище данных является единственным источником данных, что унифицирует процессы выгрузки-загрузки и упрощает их создание и сопровождение. Минусы: Имеющихся данных на момент начала работ по внедрению СПО может быть недостаточно. Это потребует выгрузки данных из систем-источников в Систему подготовки отчетности напрямую. При этом впоследствии потребуется переделка выгрузки для соблюдения единства архитектуры. Есть вероятность, что в рамках проекта по построению ХД не предполагается загрузка каких-то атрибутов или сущностей, необходимых для формирования отчетности. Уровень детализации данных, в частности раскрытия сводных счетов, в хранилище данных может не отвечать требованиям проекта СПО. Зависимость СПО от банковского хранилища данных: согласование форматов выгрузки; изменение подходов к хранению данных в ХД; дозагрузка в ХД новых атрибутов и сущностей. Двойная перегрузка (Системы-источники -

Смотрите также:


Комментарии
Минимальная длина комментария - 50 знаков. комментарии модерируются
Комментарии для сайта Cackle
Яндекс.Метрика Top.Mail.Ru
Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика Яндекс.Метрика