От ИБС к BI: эволюция банковской аналитики и отчетности

Автор: Сергей Гусев, Начальник департамента разработки систем отчетности компании "БИС"
Издание: Банковское обозрение, июнь 2013

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

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

Обязательная и управленческая

Говоря о многозначности понятия «система отчетности», нужно, в первую очередь, отметить, что сама эта система бывает двух видов: обязательная и управленческая. Каждый из них имеет свои признаки, которые определяются целым рядом параметров. Можно составить своеобразную таблицу, которая дает представление о разнице между отчетностью обязательной и управленческой.

Как видим, различия между системами определяются, во-первых, тем, для кого они предназначены, то есть потребителем, а, во-вторых, разностью задач, которые они призваны выполнять. Если обязательная отчетность должна быть сдана в срок, и никак иначе, то управленческая нужна именно тогда, когда она нужна, а не строго к 10 числу. Если от управленческой отчетности зависит принятие решения, а она еще по каким-то причинам не готова, то скорее перенесут принятие решения, чем воспользуются не вполне готовыми выкладками. Точно так же непросто и с таким показателем, как точность. Центробанк регламентирует абсолютно все, даже правила округления отчетных форм, поэтому ошибка даже в одном знаке может быть недопустимой. В случае с управленческой отчетностью абсолютная точность как раз не главное, куда важнее оперативность. Этот вид отчетности предназначен для управления бизнесом, а бизнес есть величина непостоянная, и тот отчет, что был подготовлен вчера, сегодня может быть устаревшим.
 

Виды отчетности	Обязательная	Управленческая
Потребитель	Внешний: регуляторы (Банк России, Федеральная служба по финансовым рынкам, Министерство финансов РФ).	Внутренний: руководство банка, акционеры, финансовый департамент.
Методики	Жестко регламентированные методики.	Существует множество методик, большинство из которых подготовлены западными компаниями
Сроки сдачи	Жестко регламентированы	Гибкий подход
Точность	Абсолютная	Обязательна не всегда.
Детализация	Высокая	Определяется потребностями категории пользователей

И, наконец, о методиках. Банк России жестко регламентирует методики и не позволяет вольного толкования. Однако подчеркнем, это нисколько не облегчает их использование. Методики Центробанка содержат множество нюансов, которые необходимо знать. В противном случае неприятности неизбежны. Вот почему решения, предлагаемые компанией «БИС», учитывают все особенности и тонкости этих методик. Что касается методик по управленческому отчету, тут ситуация несколько иная. Опыт управленческого отчета пришел к нам с западными консалтинговыми компаниями, а публичной литературы и возможностей обучения этим методикам у нас недостаточно. Так что здесь каждая компания принимает самостоятельное решение, какую именно методику предпочесть.

Наша практика

Компания «БИС» обладает значительным опытом разработки и внедрения решений для формирования систем отчетности и анализа. Исторически наши решения развивались следующим образом: сначала это была подсистема в составе интегрированной банковской системы QBIS.Bank, на следующем этапе мы создали решение автономное от ИБС, включив в него инструменты для загрузки, очистки и обогащения данных, получаемых из внешних систем.

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

Хранилище данных QBIS.Reporting состоит из операционного хранилища данных (ODS — operational data store) и аналитического хранилища. Каждое из них имеет свои отличительные черты:

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

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

Принципы обработки витрин

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

Принципы подготовки отчетов

Второй составляющей действия системы является подготовка отчетов. Здесь тоже важны правила, по которым строится работа. Во-первых, методики получения отчетов всегда должны находиться в актуальном состоянии. Это, пожалуй, имеет определяющее значение для подготовки обязательной отчетности. Во-вторых, используются микрокубы, то есть готовые агрегированные показатели для определенных форм отчетов. Важно отметить, что алгоритмы расчета показателей оптимизированы путем обращения только к витринам данных. Есть и еще несколько принципов, о которых тоже необходимо сказать. Нами разработан удобный интерфейс для выборки данных и просмотра готовых отчетов. Выгрузка осуществляется в форматы офисных программ, что удобно для пользователя. Также выгрузка может осуществляться в специализированные форматы регуляторных отчетов. Наконец, возможно использование Oracle BI: для построения портала отчетности интерактивных панелей (dashboards); для рассылки отчетов по расписанию; для просмотра отчетов на мобильных платформах.

Задачи

Само по себе создание современной системы отчетности, разумеется, имеет прикладное значение. Такая работа позволяет решить ряд практических задач, и первая среди них — повышение про-изводительности. Как раз одним из путей ее решения и является развитие в системе механизма «витрин данных», то есть хранилища аналитической информации, основная функция которого — сохранять массив тематической, узконаправленной информации. Задача эта решается на трех уровнях: архитектурном, технологическом и методологическом. При этом на каждом уровне приходится сталкиваться с серьезными проблемами, о чем мы сейчас и поговорим подробнее.

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

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

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

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

Хранение

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

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

Логическую структуру хранения и обработки данных можно продемонстрировать на примере расчета формы 302 (см. схему 2).

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

Производительность как проблема

Рассмотрим один из способов решения проблем производительности на примере все той же формы 302. С точки зрения технологии добавляется еще один уровень обработки (витрина данных). Расчет формы ведется на основе витрин данных, содержащих инфор-мацию по кредитным договорам, счетам и вкладам, полученным на регулярной основе. Наполнение «витрин» необходимыми данными производится регулярно, в удобное для расчетов время. Одним из плюсов данного метода расчета является существенное сокращение времени получения отчетных форм. Дополнительно мы получаем еще один уровень контроля за корректностью первичных данных (см. схему 3).

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

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

---

Скачать статью в pdf.