Практический опыт внедрения OFSA в российских Банках

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

BPM решение для Банков от Oracle

Корпорация Oracle предлагает специализированное решение для Банков – Oracle Financial Services Application (OFSA). OFSA – это комплекс приложений, позволяющий решать задачи по бюджетированию, разнесению процентов доходов и расходов, работе с трансфертами, оценке фин. рисков и др.:

• Модуль Financial Data Management – интеграция и консолидация данных, финансовая модель данных.
• Модуль Profitability Manager – аллокации, оценка эффективности.
• Модуль Transfer Pricing – расчет трансферных цен.
• Модуль   Hyperion Planning – бюджетирование и планирование (банковская модель).
• Модуль Risk Manager – управление финансовыми рисками.

В качестве средства бизнес - анализа – решение Oracle Business Intelligence.

Пример из практики

В качестве примера использования системы OFSA может послужить реализованное специалистами компании «Инфосистемы Джет» «Аналитическое Хранилище данных» в одном из российских банков.

Особенно интересным проект получился потому, что одной из задач, стоящей перед Банком, было получение отчетности для ЦБ РФ. Для реализации этого модуля потребовалась доработка (локализация) « западной » модели OFSA под реалии российского бизнеса, и благодаря реализованному проекту Банк получил возможность:

• получать информацию о рентабельности продуктов, ЦФО, клиентов и Банка в целом;
• оценивать рентабельность подразделений и возможность совершенствовать мотивацию подразделений Банка;
• получать пакет управленческой отчетности, а также средства для формирования отчетов по запросу (ad - hoc отчеты);
• автоматизировать процессы сбора данных и подготовки обязательной внешней отчетности Банка, предоставляемой в ЦБ РФ.

По функциональным областям Систему можно разделить на следующие модули:

• Модуль « Бюджетирования »
• Модуль « Управления активами / пассивами »
• Модуль « Отчетность ЦБ »
• Модуль загрузки данных

Опишем функциональность модулей поподробнее.

Модуль Бюджетирования

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

1. Трансфертное ценообразование.
2. Разнесение неоперационных расходов на продукты, точки продаж и клиентов Банка.
3. Оценка эффективности в разрезе продукта, точки продаж и клиента.
4. Оценка исполнения Инвестиционного бюджета и Сметы неоперационных расходов.
5. Оценка исполнения бизнес - плана Банка.
6. Рейтинги привлечения / размещения / эффективности.
7. Итоги работы сети.

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

Рис. 1. Схематичная структура бизнеса Банка

Схематично структуру бизнеса Банка можно представить в виде трехмерного куба, гранями которого являются Продукты, Точки продаж и Клиенты (см. рис.1 ).

Каждый элемент этого куба – Продукт, реализованный в конкретной Точке продаж конкретному Клиенту (или группе Клиентов). Это позволяет оценить не только эффективность бизнеса Банка, но и эффективность работы сети Банка и качество клиентской базы.

Основным показателем эффективности является финансовый результат (доходность) по Продукту в Точке продаж по Клиенту, определяемый из четырех составляющих:

ФР = ОР + ТР + СР + НОР

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

Участок разнесения неоперационных расходов полностью покрывается возможностями Oracle Profitability Manager. Это очень простой и в то же время емкий инструментарий, позволяющий осуществлять практически любое разнесение (не только расходов, но и доходов, объемов, статистики и др.).

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

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

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

Заключительный этап – распределение неоперационных расходов Банка с Точек продаж на Продукты и Клиента пропорционально статистике продаж.

Участок трансфертного ценообразования разработан специалистами компании « Инфосистемы Джет » самостоятельно в виду сильно отличающейся методологии Банка от той, что заложена в Oracle Transfer Pricing.

В применяемой методологии Банка происходит « виртуальная » передача ресурсов от привлекающих подразделений к размещающим. В целях трансфертного ценообразования учитываются только объемы и эффективные ставки размещения / привлечения без оглядки на состояние и поведение внешнего фона (рынки, инфляция и т. п.). Фондирование осуществляется по группам срочности. В случае нехватки пассивов подразумевается использование акционерного капитала в недостающем размере по требуемой стоимости. Трансфертная цена – среднее арифметическое между ставкой размещения / привлечения самого Продукта и ставкой привлечения / размещения фондирующих его Продуктов.

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

Модуль Управления активами / пассивами

Назначение модуля – регулярная подготовка управленческой отчетности для финансового комитета банка. Основные требования Банка звучали так: нужен автоматизированный расчет отчетов, современный аналитический функционал (например, дрилл - даун 1),  строгое соответствие итоговых печатных форм имеющимся отчетным формам в формате MS Excel, возможность прогнозирования сделок и оценки их влияния на структуру активов / пассивов Банка, их влияние на нормативы.

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

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

Блоки отчетов, реализованные в модуле, позволяют с уверенностью проводить управление ликвидностью, показывают имеющийся и прогнозный процентный гэп, маржу ( рис.2 ). Имея на руках данные о возможных разрывах в ликвидности или доходности, руководство банка может своевременно принять меры, учитывая ситуацию.  Также важно своевременно видеть возможные перекосы структуры баланса в будущем и поддерживать соответствие баланса банка нормативам ЦБ РФ: Н 1, Н 2, Н 3, Н 4. 

Рис. 2. Принципиальная схема работы модуля управления активами-пассивами.

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

В результате, модуль « Управление активами и пассивами » позволил отойти от практики многих Банков – подготовки отчетности в MS Excel вручную, и вместо этого получать отчетность автоматически из Хранилища данных OFSA.

Модуль Загрузки данных

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

На примере описываемого проекта можно продемонстрировать основные компоненты в устройстве подсистемы загрузки. В качестве сервера базы данных в этом проекте использовался Oracle 10 g, а в качестве основного ETL - инструментария –  OWB (Oracle Warehouse Bulider – также 10- й версии). Поскольку OWB в свою очередь построен на основе технологий базы данных Oracle, то их симбиоз позволяет добиваться прекрасных результатов в деле оптимизации загрузки данных.

В целом процесс загрузки подразумевает выполнение следующих основных этапов работ с данными:

1. Захват новых и измененных данных на источнике.
2. Очистка данных и преобразование в формат хранилища.
3. Обеспечение версионности критичных данных.
4. Контроль данных.

Рассмотрим подробнее каждый из этапов.

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

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

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

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

OWB, как ETL - средство, поддерживает стандартный набор операций по преобразованию данных, необходимый для всесторонней обработки входного потока: фильтры, разветвление потока по условиям, агрегация, lookup - соединения таблиц (например, для целей перекодировки кодов источника в коды хранилища), join - соединения таблиц, сортировки, простые преобразования над полями и т. д. При этом практически всегда под рукой возможность использовать подсказки оптимизатора Oracle и прочие способы улучшения производительности (например, можно влиять на характер создаваемого в базе конечного кода процессов загрузки – построчная обработка, обработка на уровне таблиц, обработка на уровне таблиц с построчной обработкой в случае ошибок и т. д.).

Рис. 3. Правила загрузки в OWB

В качестве источников OWB может работать со всеми наиболее распространенными серверами баз данных (Oracle, MS SQL Server, DB 2, Sybase и т. д.). Кроме того, поддерживаются обычные плоские файлы и ODBC- источники.

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

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

Контроль данных

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

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

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

Учитывая вышеописанную ситуацию, существует два механизма обработки / контроля ошибок.

Первый – проверять буферную stage - область (« сырые » инкрементальные данные) на ошибки и загружать в хранилище только « корректные ». А все некорректные записи складывать в специальную область, затем их корректировать и повторно загружать в хранилище.

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

Особые варианты загрузки данных

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

Для начальной загрузки возможно использование тех же ETL - процедур, что разработаны для регулярной загрузки, но когда речь идет о больших объемах, пишутся отдельные варианты процедур, учитывающие то, что хранилище изначально пусто и на вход подается очень большой кусок данных. Как правило, такие процедуры выглядят как слегка « урезанные » процедуры регулярной загрузки. Кроме того, в особо критичных ситуациях (с производительностью и временем выполнения), возможен вариант ручного написания кода соответствующих sql - процедур.

Рис. 4. Пример контрольного отчета

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

Послесловие

Внедрение бизнес - приложений от Oracle позволило банку автоматизировать бизнес - процессы бюджетирования и планирования, формирования управленческой и обязательной отчетности для Банка России, реализовать Хранилище Данных – единую информационную платформу всей ИТ - инфраструктуры Банка.

Был введен ряд новых для банка бизнес - процессов, в частности: аллокации, бюджетирование (анализ прибыльности ЦФО банка / продуктов / клиентов).

Использование инструментария Oracle Business Intelligence (Oracle BI) позволило конечным пользователям получить эффективные средства получения внутренней и внешней отчетности и аналитической работы с данными о деятельности банка.