CC BY
14
Н.Э. Иванова
СОВРЕМЕННЫЕ ПОДХОДЫ К ИНФОРМАЦИОННОМУ ОБЕСПЕЧЕНИЮ ПРИНЯТИЯ РЕШЕНИЙ В КОММЕРЧЕСКОМ БАНКЕ
Основным критерием эффективности работы системы управления коммерческим банком является своевременное и качественное обеспечение подготовки, принятия и исполнения решений по управлению текущей деятельностью и стратегическому развитию банка, организация контроля за их результативностью и эффективностью. Рассматривая управление системой банка с позиций теории принятия решений, можно представить его в виде последовательности или комплекса процессов принятия решений, сопряженных друг с другом прямыми и обратными информационными связями.
Управленческое решение является центральным элементом процесса управления, его главным действием, с помощью которого обеспечивается достижение поставленных перед банком целей: экономических результатов деятельности, имеющих, как правило, количественную оценку
- прибыль, капитал, долю рынка, отношения с внешней средой и т.д., и качественных характеристик состояния банка: устойчивой работы и эффективного развития банка, прозрачность капитала; соблюдения экономических нормативов и других нормативно-инструктивных требова-
ний, наличия систем управления рисками; разработку операционных и технологических стандартов; организацию информационного обслуживания руководства и персонала и т.д.
Одной из проблем, возникающих в процессе формирования управленческих решений, является организация обеспечения информационных потребностей (ИП) лиц, принимающих решения (ЛПР), на всех этапах этого процесса. Информационные потребности осуществляют непосредственную стыковку процессов принятия решений и их информационного обеспечения, так как выражают требования к содержанию, количественным и качественным характеристикам, срокам и форме представления информации, необходимой для принятия решений.
В данной научной работе рассматриваются современные подходы к обеспечению ИП участников системы принятия решений в коммерческом банке в рамках единого информационно-аналитического пространства.
Традиционно центральным элементом информационно-аналитического пространства банка (ИАПБ) является
2007 № 1
Вестник Ростовского государственного экономического университета «РИНХ»
автоматизированная банковская система (АБС), работающая в регламентированном режиме как трансакционная OLTP-система (Online Transaction Processing) и ориентированная, в основном, на обработку и представление руководству и сотрудникам банка внутренней учетной и отчетной информации, отражающей результаты деятельности и финансовое состояние банка, в форме документов утвержденной структуры.
Банковские OLTP-системы по своей сути являются учетными системами, поскольку осуществляют ежедневный учет всех банковских операций и доступ к базам трансакций, а в качестве целевой функции и критерия эффективности используют обработку максимального количества трансакций в единицу времени и организацию их надежного хранения. Обычно отдельные трансакции очень малы и не связаны друг с другом, однако каждую запись данных, характеризующую банковскую операцию (бухгалтерскую проводку), можно использовать для создания отчетов и различных сводок.
Для принятия любых решений по вопросам управления банковской деятельностью необходимо провести анализ, интерпретацию и обобщение полученной из OLTP-системы информации, сформировать показатели о финансовом состоянии, устойчивости и эффективности управления банком.
Показатели являются основными логическими структурными единицами банковской информации, всесторонне характеризующими деятельность банка и состояние объектов управления, и таким образом, представляют важнейший аналитический инструмент информационного обеспечения принятия решений.
Сформулируем требования ЛПР к показателям, необходимым для обеспечения ИП в процессе принятия решений по управлению банком:
1. Показатели должны отражать финансовое состояние банка на кон-
кретный момент времени (например, начало операционного дня), а также позволять оценивать его с позиций краткосрочной перспективы (показатели ликвидности, платежеспособности по срокам), средне- и долгосрочного развития (показатели оценки капитала, активов, доходности, качества управления и др.), то есть рассчитываться за определенный период времени (день, декада, месяц, квартал, год).
2. Необходимо обеспечить не только текущий расчет показателей, но и прогнозный расчет их изменения, анализ трендов.
3. ЛПР необходимо иметь возможность проводить расчеты показателей по нескольким измерениям или иерархиям, углубляться в данные (drill down) для просмотра информации на более детализированном уровне либо ограничивать множество данных их подмножеством по заданным критериям выборки.
4. Потребности ЛПР в аналитической информации динамичны и изменяются в соответствии с изменением нормативно-инструктивной базы, требований управления и внешней среды, поэтому необходимо предоставить ЛПР возможность самостоятельного ввода новых показателей и алгоритма их расчета.
5. Для обеспечения своевременности принятия решений расчет показателей должен выполняться в кратчайшие сроки (несколько секунд).
6. Для получения обобщающих, комплексных характеристик деятельности банка необходимо обеспечить группировку показателей, а также возможность расчета показателей группы.
7. Для решения планово-прогнозных задач необходимо обеспечить возможность получения и визуализации временных динамических рядов из значений показателей.
8. Для проведения различных видов финансового анализа к динамическим рядам значений показателей должны
быть применимы различные методы численного анализа (статистического, многофакторного, корреляционного).
Аналитические возможности банковских ОЬТР -систем, как правило, объективно ограничены и не предусмотрены самим назначением системы. Информация, необходимая для формирования аналитических показателей, распределена по множеству таблиц или даже отдельных систем, и для их агрегирования необходимо выполнять сложные операции объединения, что требует больших вычислительных мощностей и приводит к потере производительности. Кроме того, в банковских учетных системах хранятся постоянно изменяющиеся данные, и по мере поступления трансакций итоговые значения показателей изменяются очень быстро, что затрудняет сопоставление аналитических данных, полученных с небольшим интервалом времени. Поэтому анализ в банках обычно проводится с определенной периодичностью, как правило, по окончании отчетного периода.
Для некоторых видов анализа, особенно связанных с прогнозным поведением банковской системы, например, при проведении стресс-тестирования с целью оценки потенциального воздействия на финансовое состояние банка факторов риска, соответствующих исключительным, но вероятным событиям, необходимы структурные изменения первичных данных, храня-
щихся в OLTP-системе, что может привести к нарушению их целостности.
Современный подход к решению проблемы удовлетворения ИП руководства банка в адекватной аналитической информации, а также поступающей извне рыночной информации о событиях и условиях, имеющих отношение к принятию решений, предполагает создание интегрированного хранилища данных (date warehouse), обеспечивающего реализацию технологии комплексного многомерного анализа данных OLAP (OnLine Analytical Processing).
OLAP-технология является ключевым компонентом организации хранилищ данных, обеспечивающий единый логический взгляд и доступ к информации, накапливаемой различными банковскими OLTP-системами и поступающей из внешних источников, и позволяющий банковским руководителям провести преобразования накопленных учетных данных и сформировать такие агрегатные показатели, которые позволят наглядно отразить и проанализировать деятельность банка. Эти показатели формируются, например, путем обычных SQL-запросов, содержащих агрегатные (групповые) функции.
Банковские хранилища данных создаются в результате ежедневной выгрузки информации базы данных из банковской OLTP-системы, как правило, подсистемы АБС «Операционный день банка» (рис. 1).
Pto.I. Схема создания хранилища данных.
Хранилище данных обычно включает в себя одну или несколько таблиц фактов (facts table), а также несколько таблиц измерений, по которым может производиться группировка так называемого куба решений (design cube).
Таблицы фактов обычно являются основными таблицами хранилищ данных в системах OLAP. Как правило, они содержат сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться. К основным видам фактов банковских хранилищ данных относятся:
- факты, связанные с трансакциями (Transaction facts), основанные на отдельных событиях (например, проведение платежа по счету или снятие денег со счета с помощью банкомата);
- факты, связанные с «моментальными снимками» (Snapshot facts), основанные на состоянии объекта (например, банковского счета) в определенные моменты времени, например, на конец дня или месяца;
- факты, связанные с элементами документа (Line-item facts), основанные на том или ином документе (например, платежном поручении), содержащие подробную информацию об элементах этого документа (например, реквизитах отправителя и получателя платежа, сумме платежа и т.д.);
- факты, связанные с событиями или состоянием объекта (Event or state facts), представляют возникновение события без подробностей о нем (например, факт списания денежных средств или возникновения остатка по счету без иных подробностей).
Таблицы измерений (dimension tables), содержат неизменяемые либо редко изменяемые данные. Эти таблицы содержат как минимум одно описательное поле (обычно с именем члена измерения) и, как правило, целочисленное ключевое поле (обычно это суррогатный ключ) для однозначной идентифи-
кации члена измерения. Если будущее измерение, основанное на данной таблице измерений, содержит некоторую иерархию, то таблица измерений также может содержать поля, указывающие на «родителя» данного узла в этой иерархии. Каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов.
Например, в банковских системах всегда в качестве одного из измерений выступает дата, трактуемая как один из нескольких временных интервалов (периодов отчетности) - день, месяц, квартал, год.
Куб решений представляет многомерный набор данных, оси которого содержат параметры, а ячейки, зависящие от них агрегатные данные. Вдоль каждой оси данные могут быть организованы в виде иерархии, представляющей различные уровни их детализации. Благодаря такой модели данных руководители и специалисты банка могут формулировать сложные запросы, генерировать отчеты, получать необходимые подмножества данных.
Рассмотрим OLAP-технологию многомерного анализа деятельности банка на примере формирования аналитических показателей для оценки финансовой устойчивости банка, предусмотренных указанием Банка России от 16 января 2004 г. № 1379-У «Об оценке финансовой устойчивости банка в целях признания ее достаточной для участия в системе страхования вкладов». Для оценки финансовой устойчивости банка применяются следующие группы показателей:
- группа показателей оценки капитала;
- группа показателей оценки активов;
- группа показателей оценки качества управления банком, его операциями и рисками;
- группа показателей оценки доходности;
- группа показателей оцепкп лпк-виднocти.
Для pаcчeта этпx показателей ж-пoльзyютcя данные об активаx, капитале, кредитном портфеле, фппапcoвoм результате, дoxoдаx и pаcxoдаx банка и дру-гпе, которые целешобразно поместить в таблицы фактов, шдержащие как можно более подробные данные, то есть шот-вeтcтвyющпe членам нижиж уровней пepаpxпп измерений. В пашей модели такими таблицами фактов являются таблицы ACCOUNTS (балансі по лицевым cчeтам) (рпа2) и BALANCE (багажь! по
счетам 2-го порядка) (рис. 3).
Таблица BALANCE сформирована на основе данных баланса по счетам аналитического учета таблицы ACCOUNTS как материализованное представление, агрегированное по счетам 2го порядка, с помощью запроса, приведенного на рис.3.
Для учета отчетного периода создадим таблицу измерения времени DATE_DIM, которая будет использоваться при агрегировании информации таблицы ACCOUNTS по различным временным периодам (рис. 4).
АСС DAT INBAL TURNDT TURNCT OUTBAL
250 3010281 0300000900482 ■■■ 05.01.2000 - 23947825.73 40021 95,74 19597062,31 8362949,1 6
► 251 30102810300000900482 - 0Є.01.2000 - 8362949,1 6 23929699,28 15456051,32 6836597,1 2
252 301G281 0300G00900482 ■■■ 10.01.2000 - 1 6836597,1 2 10038070,85 18768700,35 81 03967,82
253 30102810300000900482 ■■■ 11.01.2000 - 81 03967,62 201 70770,06 11774438,81 6500298,87
254 3010281І0300000900482 ■■■ 12.01.2000 - 1 6500299,97 14907095,64 14878611,81 6528772,70
255 30102810300000900482 ■■■ 13.01.2000 - 1 6528772,70 10772667,61 15339980,27 1 961 460,04
258 30102810300000900482 ■■■ 14.01.2000 - 11 961 460,04 14532728,66 11977732,80 451 6455,90
257 30102810300000900482 ■■■ 17.01.2000 - 1 451 6455,90 25733155,23 13299822,71 !6949788,42
258 30102810300000900482 ■■■ 18.01.2000 - 26949788,42 971 4254,07 17595490,17 9068552,32
25Э 30102810300000900482 ■■■ 19.01.2000 - 1 9068552,32 732981 6,25 14334964,32 2062504,25
2Є0 30102810300000900482 ■■■ 20.01.2000 - 1 2062504,25 11173669,57 975361 8,99 3482554,94
2Є1 30102810300000900482 ■■■ 21.01.2000 - 1 3482554,84 14451 489,97 10735255,37 71 98769,44
262 30102810300000900482 ■■■ 24.01.2000 - 1 71 98769,44 8740088,90 1569021 6,81 0248641,53
263 30102810300000900482 ■■■ 25.01.2000 - 1 0248641,53 141 64976,23 13094943,95 1 31 8673,81
264 30102810300000900482 ■■■ 26.01.2000 - 11 31 8673,91 12336894,81 11679062,03 1 976506,59
265 30102810300000900482 ■■■ 27.01.2000 - 11 976508,59 120631 00,78 8386897,74 5872709,83
26G 30102810300000900482 ■■■ 28.01.2000 - 1 5872709,83 18407114,85 1831 4203,12 5765821,36
267 30102810300000900482 ■■■ 31.01.2000 - 1 5765621,36 1004861 0,40 101 42966,67 5671 265,09
260 30102810300000900482 ■■■ 01.02.2000 - 1 5Є71 265,09 671 3457,25 8590040,37 3794681,97
269 30102810300000900482 ■■■ 02.02.2000 - 1 3794681,97 177351 91,04 131 08381,59 8421 481,42
Риа 2. Фрагмент таблицы фактов ACCOUNTS.
create materialized view balance build immediate refresh complete on demand enable query rewrite as
select substr(acc,1,3) as accl, substr(acc,1,5) as acc2, dat,
mmyyyy, mon_yyyy, qtr_yyyy, yyyy,
sum(round(inbal,2)) as i,
sum(round(turndt,2)) as tdt,
sum(round(turnct,2)) as tct,
sum(round(outbal,2)) as o
from accounts a, date_dim d
where (inbal+turndt+turnct+outbal <> 0) and
(a.dat=d.day)
group by substr(acc,1,3), substr(acc,1,5), dat, mmyyyy, mon_yyyy, qtr_yyyy, yyyy
Рис. 3. Формирование талицы ACCOUNTS
Помимо перечисленных основных таблиц, для расчета показателей могут применяться некоторые дополнительные таблицы. Например, в соответствии с Положением Банка России №205-П от 05.12.2002 «Правила ведения бухгалтерского учета в кредитных организациях, расположенных на территории РФ» для формирования отчетности и учета финансового результата, осуществляется группировка доходов и расходов, однородных по экономическому содержанию по статьям, в том числе по источникам доходов и направлениям расходов. Группировка осуществляется по пятизначным символам аналитической схемы доходов и расходов, в структуре которых первая цифра
означает номер раздела, вторая - номер подраздела, третья цифра - номер группы, четвертая и пятая - номер статьи. Таким образом, символы доходов и расходов образуют правильную иерархическую структуру, позволяющую получать итоговые значения показателей в разрезе различных уровней группировки.
Для классификации символов доходов и расходов создадим таблицу SYMBOLS которая представлена на рис. 5.
Значение VAL в таблице SYMBOLS представляет значение текущего символа за текущий месяц, TOT- значение символа нарастающим итогом с начала текущего года за каждый месяц.
DAY MMYYyY MON YYyY QTR YYyY YYyY
► 1 03.01.2000 - 12000 янб-2000 Q12000 - 2000
2 05.01.2000 - 12000 янб-2000 Q12000 ■■■ 2000
3 06.01.2000 - 12000 янб-2000 Q12000 ■■■ 2000
4 10.01.2000 - 12000 янб-2000 Q12000 ■■■ 2000
5 11.01.2000 - 12000 янб-2000 Q12000 ■■■ 2000
G 12.01.2000 - 12000 янб-2000 Q12000 ■■■ 2000
7 13.01.2000 - 12000 янб-2000 Q12000 ■■■ 2000
■ 8 14.01.2000 - 12000 янв-2000 Q12000 ■■■ 2000
Э 17.01.2000 - 12000 янв-2000 Q12000 ■■■ 2000
10 18.01.2000 - 12000 янб-2000 Q12000 - 2000
11 18.01.2000 - 12000 янб-2000 Q12000 ■■■ 2000
12 20.01.2000 - 12000 янб-2000 Q12000 ■■■ 2000
■ 13 21.01.2000 - 12000 янб-2000 Q12000 ■■■ 2000
Рис. 4. Таблица измерения времени DATE DIM.
create table SYMBOLS (
ID NUMBER not null,
PARENTID NUMBER,
LEV NUMBER,
SYM CHAR(5) not null,
NAME VARCHAR2(250),
constraint PK_SYMBOLS primary key (SYM)
)
organization index;
Рис. 5. Создание таблицы символов отчетности о доходах и расходах
Для хранения данных по символам доходов и расходов в модели используется реляционная таблица SYM_VAL, которая пополняется по истечении каждого отчетного месяца. На рис. 6 представлен PL/SQL- скрипт, формирующий таблицу SYM_VAL из таблицы ACCOUNTS.
вола cooтвeтcтвyют poдитeльcким балап-швым cчeтам 1-го порядка.
В нашей ОЬЛР-модели также используется иерархически организованная таблица плана счетов ЛСС_РЬЛЫ (рис. 7), где в качестве записей-потомков используются пятисимвольные балансовые счета 2-го порядка, у которых первые три сим-
В таблице ACC_PLAN содержатся одновременно счета 1-го и 2-го порядков плана счетов. Поле ACC2 содержит символы счета, LEV отражает уровень вложенности, TYP- тип счета (активный или пассивный). Поле KIND отражает разработанную нами группировку счетов, согласно которой оно является внешним ключом в таблицу - классификатор видов счетов ACC_KIND (рис. 8).
create table sym_val as select day, sym, val, sum(val)
over(partition by sym, to_char(day,'YYYY') order by sym, day) tot from
(select max(dat) as day,
substr(acc,14,5) as SYM, sum (turndt+turnct) as VAL from accounts, date_dim
where (substr(acc,1,3)='701' or substr(acc,1,3)='702')) and dat=day and turndt+turnct<>0
group by mmyyyy, dat, substr(acc,14,5)
create table ACC_PLAN (
ID NUMBER not null,
PARENTID NUMBER not null,
ACC1 CHAR(3)not null,
ACC2 CHAR(5)not null,
LEV NUMBER,
TYP CHAR(1),
CHAP CHAR(1),
NAME VARCHAR2(250),
KIND CHAR(2),
constraint PK_ACC2 primary key (ACC2),
constraint FK_KIND foreign key(kind) references ACC_KIND(kind)
)
organization index;
Pпc. 6. Формирование таблицы SYM_VAL.
Pto. 7. Создание таблицы ACC_PLAN
Применяя таблицу - размерность TIME_DIM, содержащую в себе различные временные периоды банковской работы и отчетности, совместно с полученными материализованными представлениями, можно сформировать различные временные ряды, а также рассчитать банковские показатели на конкретную дату.
Например, для того чтобы получить динамику процентных доходов банка за 2000-й год, необходимо выполнить запрос, который представлен на рис. 9.
В результате выполнения запроса формируется временной ряд Bar Series и соответствующий график Bar Chart (рис.10).
1 KIND 1 KINDNAME 1
> 1 1 Счета по учету капитала банка
2 2 Счета по учету фондов банка
3 3 Наличные денежные средства
4 4 Корреспондентские счета
5 5 Ссудные и приравненные к ним счета
6 6 Депозиты и прочие привлеченные средства
7 7 Расчетные счета клиентов
S S Счета по учету созданных банком резервов
9 9 Счета по учету операций с ценными бумагами и долговыми обязательствами
10 10 Имущество и вложения банка
11 11 Результаты деятельности
12 12 Средства в расчетах
13 13 Предстоящие поступления и выплаты
Рис. S. Фрагмент классификатора видов счетов ACC KIND.
Select t.day, d.mon_yyyy, substr(sym,1,2) as sym, sum(val)val from sym_val t, date_dim d where (substr(sym,1,2) = '11') and (d.day = t.day) and (yyyy=2000) group by t.day, d.mon_yyyy, substr(sym,1,2) order by t.day
Рис. 9. Структура запроса по динамике процентных доходов банка
DAY MON Ші SYM VAL
► 1 31.01.2000 - янб-2000 11 182588,43
2 23.02.2000 - Фев-2000 11 358272,38
3 31.03.2000 - мар-2000 11 338078,83
4 28.04.2000 - апр-2000 11 288388,74
5 31.05.2000 - май-2000 11 367645,45
Є 30.06.2000 - нюн-2000 11 368518,84
7 31.07.2000 - нюл-2000 11 335118,27
8 31.08.2000 - авг-2000 11 302268,86
8 28.08.2000 - сен-2000 11 335445,7
10 31.10.2000 - окт-2000 11 368433,88
11 30.11.2000 - ноя-2000 11 408283,88
12 28.12.2000 - дек-20&0 11 481338,88
Рис. 10. Динамика процентных доходов банка
Предложенная нами технология позволяет получать подобные временные ряды-серии и графики для любых счетов и символов во временных разрезах, представленных в таблице с1а1е_сНт.
Для информационного обеспечения принятия отдельных решений по функционально автономным задачам или в самостоятельных структурных подразделениях банка используются так называемые витрины данных, в которые информация попадает либо из хранилища (зависимые витрины), либо непосредственно из источников данных, проходя необходимую фильтрацию и преобразования (независимые витрины).
Витрины данных наиболее часто представляют подмножества данных из хранилища, организованные для решения задач отдельных подразделений банка (например, кредитный отдел). При подготовке информации для принятия решения о выдаче кредита сотрудниками кредитного отдела, для оценки платежеспособности и кредито-
способности заемщика используются данные об экономическом положении и финансовом состоянии заемщика, технико-экономическом обосновании кредита, возможных вариантов обеспечения возврата кредита и предметов залога и другая информация, которая может быть собрана в зависимой витрине данных. Данные о кредитной истории заемщика целесообразно получить из независимой витрины данных, образованной на базе информации, представленной бюро кредитных историй, и самим заемщиком.
Преимуществом витрин данных является оптимизация хранимой в них информации для определенной категории банковских специалистов, однако при большом количестве источников данных возникает проблема пополнения данных и их непротиворечивости.
Использование витрин для анализа информации при подготовке решений не исключает доступа к хранилищам данных для получения необходимой дополнительной информации.
