© 1995-2021 Компания «Инфосистемы Джет»
Практический опыт внедрения OFSA в российских Банках
Программное обеспечение

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

Программное обеспечение Тема номера

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

14.08.2009

Посетителей: 100

Просмотров: 90

Время просмотра: 1.2 мин.

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

 

 

Однако « собрать » данные – далеко не вся задача, помимо этого требуются инструменты для обеспечения цикла управления: формирование стратегии, планирование, исполнение планов. Для решения этих задач существует целый класс систем – BPM (Business Performance Management). Что из себя представляют системы такого класса ?

 

Функциональная архитектура классической BPM - системы складывается из трех составных частей. Первая часть – Хранилище данных. Это базис BPM- системы. В нем консолидируется оперативная финансовая информация из различных систем учета. Вторая составляющая решения – набор инструментов для поддержки технологий управления предприятием: финансового планирования, управленческого учета, прогнозирования и т. д. Третья компонента BPM – средства OLAP для оперативной работы с деловыми данными, которые накапливаются в Хранилище.

 

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

Для облегчения процесса внедрения существует деление (специализация) 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) позволило конечным пользователям получить эффективные средства получения внутренней и внешней отчетности и аналитической работы с данными о деятельности банка.

Уведомления об обновлении тем – в вашей почте

«ИТ — это не конкурентное преимущество, а конкурентное требование»

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

Open UI – новая концепция пользовательского интерфейса

Oracle Siebel CRM представляет Open UI (Open User Interface) – новую концепцию пользовательского интерфейса

«Хайп прошел, пора строить». Data Lake выпуска 2021 г.

Когда озеро данных становится болотом? Что выбрать: Open Source или вендорские решения? Почему локальные озера данных в России популярнее облачных?

Теперь можно Exadata’ться по полной

В ноябре прошлого года наша компания получила авторизацию на оказание услуг «Installation & Configuration» для программно-аппаратных комплексов Oracle Exadata Database Machine и Oracle Exadata Storage Expansion Rack

Интеграционные проекты - работа над ошибками

Реализация интеграционных проектов редко обходится без сложностей. Мы рассматриваем способы их преодоления

Стратегия развития Oracle Siebel CRM

Oracle выпустил документ, посвященный направлениям развития платформы Oracle Siebel CRM и ее новым возможностям

Стратегия развития Oracle Siebel CRM: автономность, гибкость, отраслевые решения, удобство использования

Siebel CRM — ключевой продукт из категории решений для обслуживания клиентов (CX). В стратегии развития Siebel CRM Oracle делает упор на удобство использования, быструю адаптацию к требованиям бизнеса, отраслевые инновации и автономность.

Изучение Oracle In-Memory и SQL in Silicon

Одной из существенных инноваций процессора M7 является возможность переноса части SQL-логики на специальные сопроцессоры DAX (Data Analytics Accelerator). Эта технология получила название SQL in Silicon.

Комплексный подход к защите данных. Все по делу, никаких смузи!

Почти все наши заказчики, внедрившие себе системы резервного копирования (СРК), думают, что на этом все их проблемы решены.

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня