Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Публикации

Аналитический банковский журнал

Как обеспечить качество данных для обязательной отчетности банка

Автоматизация обязательной отчетности по-прежнему остается нерешенной задачей для многих отечественных банков. После того, как были приняты базельские стандарты оценки достаточности капитала, подготовка отчетности для Банка России существенно усложнилась, однако кредитные организации продолжают применять для этих целей неэффективные технологии на основе Excel-таблиц и учетныe модули АБС. Такие инструменты не позволяют в полном объеме автоматизировать расчет обязательных нормативов, в результате сотрудники банков ежедневно вынуждены вручную подготавливать данные для этой формы.

Сами банкиры недовольны сложившейся ситуацией, о чем свидетельствуют хотя бы данные опроса участников встречи с Банком России «Новое в практике расчета обязательных нормативов банков»[1]. Большинство опрошенных (70 %) оценили имеющиеся в их банках технологии подготовки нормативов как несоответствующие ужесточившимся требованиям регулятора.

В ближайшей перспективе Банк России будет продолжать сближение с принципами «Базеля II». Сегодня обсуждается возможность поэтапного внедрения IRB-подхода (Internal Rating-based Approach) к определению достаточности капитала на основе внутрибанковских рейтингов заемщиков. Чтобы подготовиться к реализации такого подхода и обеспечить получение объективных рейтинговых оценок, банкам предстоит накопить качественную информацию по заемщикам за продолжительный период. Приступать к этой задаче лучше уже сейчас, и первым шагом должен стать пересмотр применяемых технологий подготовки данных для формирования обязательной отчетности.

Почему качество данных критически важно

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

На исполнение проекта автоматизации отчетности на основе хранилища данных может потребоваться до полутора лет. При этом на работы по сбору и подготовке данных уходит до 70 % трудозатрат, и лишь 30 % – на автоматизацию отчетных форм. Таким образом, сроки и стоимость проекта напрямую зависят от качества исходных данных.

Почему качество данных нужно оценить прежде, чем приступить к проекту автоматизации отчетности

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

Самый распространенный случай, когда работы по обеспечению качества данных просто не закладываются в проект. Исполнитель приступает к созданию хранилища и сбору данных, намеревается в ближайшее время начать внедрение отчетных форм, а ему как ком на голову вдруг сваливаются внеплановые задачи. Во-первых, оказывается, что в учетных системах данных недостаточно: счета и сделки не имеют необходимых атрибутов, нет информации о связях заемщиков, некоторые сделки вообще не учитываются в автоматизированных системах. Во-вторых, обнаруживается масса ошибок в данных. Это могут быть ошибки, связанные с методологией учета. Например, неверное ведение аналитического учета срочных сделок. Если сделки не учитываются в разрезе каждого договора, как регламентирует Положение Банка России № 302-П, а в АБС на одном лицевом счете суммируются остатки от сделок различной срочности, то практически невозможно автоматизировать расчет величины кредитного риска по срочным сделкам (КРС) для норматива достаточности капитала банка (Н1).

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

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

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

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

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

Пилотный проект по оценке качества данных

При автоматизации банковской отчетности минимизировать риски, связанные с низким качеством данных, помогает выполнение специального «пилотного проекта». Западные компании уже активно практикуют такой подход в проектах построения хранилищ данных. Этот факт отмечен в прошлогоднем исследовании Gartner «Магические квадранты для СУБД Хранилищ данных»[2]. При выполнении «пилотов» аналитики рекомендуют уделять особое внимание процессам загрузки и контроля данных, даже если это неглавное требование к будущей системе на основе хранилища.

На российском рынке пилотные проекты по оценке качества исходных данных для отчетности выполняет компания Intersoft Lab – отечественный поставщик хранилищ данных и систем класса Business Performance Management (BPM) для кредитных учреждений. Цель данной услуги – помочь банку сформировать реалистичные ожидания от предстоящей автоматизации обязательной отчетности, разработать объективный план будущего проекта, проверить возможности применения штатных ETL-инстументов BPM-системы для сбора данных или обосновать необходимость приобретения интеграционного ПО.

Пилотный проект компания выполняет в ограниченные сроки – до 3-х месяцев. За это время в банке внедряется хранилище данных и тестовый пакет отчетности. Данные для отчетности, поступающие в хранилище из эксплуатируемых учетных систем, проходят целый комплекс проверок. В результате формируются отчеты о достаточности и качестве данных. Полученные документы помогают определить масштабы предстоящих работ по организации процессов сбора, выверки и обогащения данных. Чтобы гарантировать заказчику оперативный выпуск ежедневных отчетных форм (таких как, например, обязательные нормативы банка), проводится оценка производительности процедур загрузки на реальных объемах данных банка. Если по итогам этой поверки штатные ETL-инструменты BPM-системы не обеспечивают необходимые скорость загрузки данных и запас производительности с учетом роста их объемов, банку рекомендуется внедрение промышленной интеграционной платформы.

Пилотные проекты компания Intersoft Lab реализует на основе собственной методической модели, разработанной для целей автоматизации банковской отчетности на BPM-платформе «Контур». Модель аккумулирует опыт выполнения более 70 проектов в банках и содержит знания о подготовке различных видов отчетности: для Банка России, налоговой, управленческой, аналитической и др. В модели описаны состав и атрибуты исходных данных для формирования каждого отчета, алгоритмы контроля и обогащения данных, алгоритмы расчета показателей отчетов. Эти знания позволяют сразу понять, достаточно ли данных в учетных системах для подготовки отчетности, выявить ошибки в данных и использовать специальные алгоритмы для обеспечения качества данных. Mодель помогает провести диагностику данных в минимальные сроки, а также оптимизировать предстоящий проект автоматизации отчетности. Проект выстраивается таким образом, чтобы заказчик как можно скорее начал получать отдачу: система поэтапно наращивается с помощью отдельных блоков методической модели и после каждого этапа в промышленную эксплуатацию вводится определенный комплект отчетности.

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

Что получает банк в результате пилотного проекта

По завершении пилотного проекта банку предоставляется:

  • План проекта автоматизации отчетности с подробным указанием состава работ, сроков и трудозатрат каждого его этапа. Заказчику будут очевидны сроки ввода в эксплуатацию каждой отчетной формы;
  • Требования к качеству данных. Заказчику будет предложен комплекс организационно-технических мер по повышению качества данных не только на уровне хранилища данных, но и в учетных системах. Это позволит улучшить состояние данных в масштабах всей ИТ-инфраструктуры банка;
  • Обоснование необходимости использования промышленной интеграционной платформы с оценкой планируемого экономического эффекта от ее внедрения. Банк сможет взвешено подойти к приобретению интеграционной платформы и оценить сроки возврата инвестиций в ПО;
  • Описание ограничений предстоящего проекта. Еще до начала проекта банк будет проинформирован об ограничениях, связанных с применяемыми методологиями учета и средствами автоматизации, а также получит рекомендации по их устранению для реализации функциональности в полном объеме;
  • Потенциальные риски проекта с предложением по их минимизации.

Выполняя пилотные проекты по оценке качества данных, компания Intersoft Lab помогает банкам начинать строительство системы обязательной отчетности с надежного фундамента. Банк получает четкое представление о составе работ, сроках и затратах на автоматизацию отчетности и начинает реализацию проекта с открытыми глазами.


[1] Встреча коммерческих банков с Банком России «Новое в практике расчета обязательных нормативов банков» состоялась 22 июня 2010 г. и была посвящена обсуждению методологии расчета обязательных нормативов банков и технологии ее автоматизации.

[2] Feinberg Donald, Beyer Mark A. Магические квадранты для СУБД Хранилищ данных (Magic Quadrant for Data Warehouse Database Management Systems) // Gartner RAS Core Research Note G00173535. – 2010, 28 января.

Автор: В. Чаусов, Е. Трунова
Источник: Аналитический банковский журнал, 2011, № 4