С чего начать внедрение хранилища данных для регуляторной отчётности

Зачем банку тестировать отечественный софт для автоматизации обязательной отчётности, и как организовать пилотный проект для регуляторного хранилища данных – в материале Юлии АМИРИДИ, заместителя генерального директора Интерсофт Лаб.

Зачем нужен пилотный проект для хранилища данных

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

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

Убедиться, что отечественный софт не подведёт, позволяет пилотный проект, отражающий специфику использования ХД в банке в ближайшие 3–4 года эксплуатации. Цель «пилота» – проверить осуществимость, уточнить сроки и оценить риски создания ХД и решения первой прикладной задачи на конкретной программной платформе силами выбранного подрядчика. Реализация пилотной стадии предваряет окончательное решение банка о выборе ПО и исполнителя проекта.

Для пилотного внедрения выбирается типичная, ограниченная по срокам реализации часть основного проекта.

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

Как организовать пилотный проект для регуляторного хранилища данных

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

Пилотный проект для регуляторного ХД – это миниатюра масштабного проекта автоматизации регуляторной отчётности. Его задача – протестировать реализацию полного цикла подготовки обязательной отчётности – от сбора данных из систем-источников банка в ХД до выгрузки готовой формы в программный комплекс «Дельта» Банка России.

Пилотная стадия предполагает внедрение 1–2 отчётных форм из согласованного скоупа проекта. Формы выбираются так, чтобы реализация «пилота» под ключ заняла не более 6 месяцев. Поскольку сбор в ХД данных по договорам требует бóльших сроков, для тестового внедрения предпочтительно взять отчёты, которые можно подготовить на данных бухгалтерского учёта. Типичный выбор для «пилотирования» – Приложения к Положению 753-П, форма 0409345 «Данные о ежедневных остатках подлежащих страхованию денежных средств, размещённых во вклады», Реестр обязательств банка перед вкладчиками и т.п.

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

В идеале пилотное внедрение выполняется на реальных объёмах данных, загружаемых из операционных источников банка, и включает все этапы, присущие проекту построения регуляторного ХД:

1. разворачивание хранилища на разрешённой СУБД в тестовой среде банка;
2. интеграцию ХД с учётной системой банка с использованием разрешенных ETL-инструментов и загрузку в ХД данных, атрибутный состав которых как минимум обеспечит выпуск тестовых форм;
3. профилирование данных в ХД и настройку необходимых контролей качества;
4. подготовку технического задания на внедрение пилотных форм с учётом индивидуальных особенностей их подготовки в банке;
5. установку и настройку прикладной функциональности;
6. обучение пользователей работе с ПО;
7. тестирование выпуска формы на заданном периоде и сверку результатов с эталоном.

Специалисты заказчика привлекаются к реализации всех этапов пилотной стадии в объёме, который предусматривает основной проект. Минимальный объём участия – консультирование исполнителя по особенностям технологии выпуска форм в банке, согласование технического задания и приёмка результатов. Если используется тиражный софт с готовой финансовой моделью данных, то возможно привлечение специалистов банка к работам по выгрузке данных из источников банка и/или их загрузке в ХД.

Непосредственное участие в пробном проекте помогает банку:

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

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

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

Источник: Национальный банковский журнал (NBJ)