|
Untitled Document
 А. Бовин
Компания "ФОРС-Центр разработки"
Департамент по работе с финансовыми институтами
OFSA
Основные принципы. Часть 6.
Визуализация финансового хранилища данных.
Новые возможности.
Источник: сайт компании "ФОРС-Центр разработки",
http://www.fdc.ru/pls/portal/docs/PAGE/FDC_RU/ORACLE.FDC.RU/WORK_FILES/OFSA_MAIN_ARTICLE_6.PDF
[От редакции OMRE: Мы завершаем публикацию серии из шести статей А.Бовина, сотрудника Департамента по работе с финансовыми институтами компании "ФОРС- Центр разработки". Ранее в нашем журнале были опубликованы:
Вся эта большая работа А. Бовина находится на сайте "ФОРС-Центр разработки" по адресу: http://www.fdc.ru/portal/page?_pageid=41,196160&_dad=portal&_schema=PORTAL . ]
«Информация должна возникать из информации,
как организм - из организма».
Станислав ЛЕМ
«Сумма технологии»
Оглавление.
1. Введение.
2. Агрегирование и детализация данных – начало.
3. Немного SQL – структура представления.
4. Агрегирование и детализация данных – продолжение.
5. Демонстрационная модель – настройки.
6. Демонстрационная модель – результаты.
7. Некоторые возможности.
8. Пример отображения VAR .
9. Использование картографических данных.
10. Заключение.
- Введение.
Основная тема статьи – визуализация бизнес-аналитической информации финансового хранилища данных OFSA FDM , в том числе формирование обязательной отчетности ЦБ РФ. До недавнего времени основным инструментом визуализации являлся Discoverer (сейчас включен в пакет Oracle Business Intelligence Standard Edition ), но в настоящее время на первое место выходит новый набор продуктов бизнес анализа - Oracle Business Intelligence Enterprise Edition ( BI EE ), примеры использования которого будут представлены в данной статье. BI Enterprise Edition ориентирован на работу в гетерогенной среде, первое представление можно получить на сайте www.oraclebi.ru , в том числе там дается развернутое определение термина « d ashboard» и также на сайте http :// bi . fors . ru .
Статью о совместном использовании OFSA и BI EE можно найти здесь: www.oracle.com/industries/financial_services/oracle-financial-services-profitability-analytics-ds.pdf
- Агрегирование и детализация данных – начало.
Ниже предлагается пример традиционного анализа, построенный на консолидации и детализации данных, когда в начале демонстрируются отчеты с максимальным обобщением данных, а затем предполагается последовательная детализация.
Использование на детальном уровне записей финансовых инструментов (конкретные ссуды, депозиты, ценные бумаги и т.п.) дает аналитику наибольшую определенность, например, позволяет однозначно судить об условиях возврата ссуды или возможности продажи какого-либо актива.
Предлагаемые ниже примеры демонстрируют возможность жестко не разрывать формирование обязательной и аналитической отчетности, в качестве примера взяты отчеты 0409128/0409129. Данный выбор определяется, в первую очередь, структурой этих отчетов. Действительно, если сравнить два отчета: форму 0409128 (0409129) и Приложение 9 (ГЛАВА А. БАЛАНСОВЫЕ СЧЕТА), то с начала создается впечатление, что первый отчет существенно сложнее. Но внимательное изучение структуры второго отчета неизбежно вызывает в памяти жемчужины народной мудрости, что-то вроде «не говори гоп, пока …» и аналогичные.
Отчет «Приложение 9» носит ярко выраженный «мозаичный» характер, если в оборотном балансе (Приложение 8) строки отчета и промежуточные итоги выводятся в естественном порядке следования счетов 2-го порядка, то в данном отчете имеется значительное количество исключений. Например, строка - «298.ИМУЩЕСТВО, ПОЛУЧЕННОЕ В ФИНАНСОВУЮ АРЕНДУ (ЛИЗИНГ) ЗА МИНУСОМ АМОРТИЗАЦИИ (СЧЕТ N 60804 - СЧЕТ N 60805)». В отчете имеются строки с числовыми результатами и чисто текстовые строки (подзаголовки). Совершенно ясно, что подобные отчеты требуют и разработки отдельного приложения (в рамках модуля « Обязательная отчетность ») и наличия в этом приложении специального блока для настройки.
В то же время структура отчета 0409128 «Данные о средневзвешенных процентных ставках по кредитам» определяется в большей степени правилами, а не исключениями. Поэтому, имея хорошо спроектированное финансовое хранилище данных и мощную систему визуализации (формирования аналитических отчетов), можно получить подобный отчет естественным образом, т.е. без разработки специального приложения.
На следующем дашборде таблица u является объединением двух отчетов (0409128 и 0409129). Отличия данного отчета от «канонического» незначительны – нет строки «… в том числе» и добавлена дополнительная строка стратификации (группа срочности). Подробное описание представления для получения отчета приводится в следующем разделе.
|
Дашборд 1. Отчеты с максимальным обобщением данных. |
Таблица v дашборда формируется практически на том же представлении (дополнительная выборка за период предыдущего года), прототип данного отчета взят из документа «Вестник Финансовой академии» за 2006 год № 3 (39). В этом отчете используются элементы горизонтального (сравниваются данные текущего и предыдущего периодов) и вертикального (относительные оценки) анализа.
Не представляет труда, используя технику перетаскивания ( drag and drop ), на основе этих двух отчетов получить несколько других. Например, в первом отчете можно перенести в позицию «Страниц» колонку «Имя финансового инструмента», а для второго отчета в позицию «Страниц» колонку «Тип клиента» и т.п., что позволит получать новые отчеты с более детализированной информацией.
- Немного SQL – структура представления.
Отчеты, представленные выше, получены на демонстрационной БД, поставляемой вместе с OFSA . Для получения отчетов используется достаточно простое, хотя и громоздкое представление, объединяющее все необходимые (с точки зрения форм 0409128/0409129) информационные структуры по привлечению и размещению средств, т.е. финансовые инструменты и массив лицевых счетов.
CREATE OR REPLACE VIEW ALL_INSTRUMENTS_V AS SELECT ' Коммерческие ссуды ' Name_Insrt, 'A' AP, … FROM Commercial_Loan t1 WHERE … UNION
SELECT ' Инвестиции ' Name_Insrt, 'A' AP, … FROM Investments t2 WHERE … UNION
SELECT ' Срочные депозиты ' Name_Insrt, 'P' AP, … FROM Term_Deposits t3 WHERE … UNION
SELECT ' Потребительские кредиты ' Name_Insrt, 'A' AP, … FROM Consumer_Loan t4 WHERE … UNION
SELECT ' Оптовый банковский бизнес ' Name_Insrt, 'P' AP, … FROM Wholesale_Funding t5 WHERE … UNION
SELECT ' Депозиты ' Name_Insrt, 'P' AP, … FROM Deposits t6 WHERE … UNION SELECT ' Лиц . Счета - Предоставленные ' Name_Insrt, 'A' AP, … FROM Acct tt1 WHERE …
UNION SELECT ' Лиц . Счета - Привлеченные ' Name_Insrt, 'P' AP, … FROM Acct tt 2 WHERE … |
Схема 1. Скелет представления для формирования отчета. |
Структура отдельного оператора SELECT представления приводится ниже, для простоты и сокращения некоторые фрагменты опущены, например, фрагмент по определению типа клиента, т.к. он зависит от специфики демонстрационной базы данных.
SELECT 'Срочные депозиты' Name _ Insrt –- имя финансового инструмента , ' P ' AP –- индикатор предоставленные средства/привлеченные средства , t 3. Identity _ Code –- Идентифицирует источник данных , t 3. Id _ Number -- Уникальный идентификатор записи, такой как номер счета , t 3. As _ Of _ Date -- Дата для текущих данных ,t3.Common_Coa_ID -- Номер счета COA ,t3.GL_Account_ID -- Номер счета GL ,t3.Iso_Currency_Cd -- Код валюты ,t3.Product_Type_CD -- Тип продукта , t 3. Interest _ Rate _ Cd -- Код процентной ставки , t 3. Compound _ Basis _ Cd -- Базис начисления сложных процентов , t 3. Adjustable _ Type _ Cd -- Частота или метод регулирования купона или ставки , t 3. Accrual _ Basis _ Cd -- База для начисления процентной ставки по счету , t 3. Cur _ Net _ Rate -- Текущая номинальная процентная ставка , t 3. Cur _ Book _ Bal -- Текущий остаток главной книги в валюте счета , t 3. Org _ Book _ Bal -- Остаток главной книги на дату происхождения , t 3. Maturity _ Date -- Дата завершения инструмента , t 3. Origination _ Date -- Дата происхождения инструмента ,t3.Maturity_Date - t3.Origination_Date Srok -- Срочность ( в днях ) ,DECODE(t3.iso_currency_cd, 'RUR' , t3.cur_book_bal,OFSA_RATES.CONVERT_BALANCE(t3.Cur_Book_Bal, t3.Iso_Currency_Cd, 'RUR' , t3.As_Of_Date)) Cur_Book_Bal_1 -- Текущий остаток главной книги в -- рублях . См . примечание 1. ,DECODE(t3.iso_currency_cd, 'RUR' , t3.cur_book_bal,OFSA_RATES.CONVERT_BALANCE(t3.Cur_Book_Bal, t3.Iso_Currency_Cd, 'RUR' , t3.As_Of_Date)) * t3.Cur_Net_Rate Rate_Bal -- См . примечание 2. ,DECODE(t3.iso_currency_cd, 'RUR' , t3.cur_book_bal,OFSA_RATES.CONVERT_BALANCE(t3.Cur_Book_Bal, t3.Iso_Currency_Cd, 'RUR' , t3.As_Of_Date)) *(t3.Maturity_Date- t3.Origination_Date) Srok_Bal -- См . примечание 3 ,DECODE(LEAST(GREATEST(t3.Maturity_Date - t3.Origination_Date, 0 ), 0 ),t3.Maturity_Date - t3.Origination_Date, '1.1. До востребования' ,
DECODE(LEAST(GREATEST(t3.Maturity_Date - t3.Origination_Date, 0 ), 1 ),t3.Maturity_Date - t3.Origination_Date, '1.2. На 1 день' ,
DECODE(LEAST(GREATEST(t3.Maturity_Date - t3.Origination_Date, 2 ), 7 ),t3.Maturity_Date - t3.Origination_Date, '1.3. От 2 до 7 дней' ,
DECODE(LEAST(GREATEST(t3.Maturity_Date - t3.Origination_Date, 8 ), 30 ),t3.Maturity_Date - t3.Origination_Date, '1.4. От 8 до 30 дней' ,
DECODE(LEAST(GREATEST(t3.Maturity_Date - t3.Origination_Date, 31 ), 90 ),t3.Maturity_Date - t3.Origination_Date, '2. От 31 до 90 дней' ,
DECODE(LEAST(GREATEST(t3.Maturity_Date - t3.Origination_Date, 91 ), 180 ),t3.Maturity_Date - t3.Origination_Date, '3. От 91 до 180 дней' ,
DECODE(LEAST(GREATEST(t3.Maturity_Date - t3.Origination_Date, 181 ), 365 ),t3.Maturity_Date - t3.Origination_Date, '4. От 181 дня до 1 года' ,
DECODE(LEAST(GREATEST(t3.Maturity_Date - t3.Origination_Date, 366 ), 1095 ),t3.Maturity_Date - t3.Origination_Date, '5. От 1 года до 3 лет' ,
DECODE(LEAST(GREATEST(t3.Maturity_Date - t3.Origination_Date, 1096 ), 3650 ),t3.Maturity_Date - t3.Origination_Date, '6. От 3 лет до 10 лет' ,
DECODE(LEAST(GREATEST(t3.Maturity_Date - t3.Origination_Date, 3651 ), 99999 ),t3.Maturity_Date - t3.Origination_Date, '7. Свыше 10 лет' , 'ERROR' )))))))))) Strat -- Формирует интервалы стратификации ( группы срочности ) FROM Term_Deposits t3 WHERE … |
Схема 2. Структура отдельного оператора SELECT |
Примечание 1. В колонке Cur_Book_Bal_1 определяется текущий остаток главной книги в рублях, т.к. «… объем операций в иностранной валюте пересчитывается в рубли по официальному курсу иностранных валют по отношению к рублю, установленному Банком России на отчетную дату». OFSA FDM обеспечивает группу хранимых функций и процедур для формирования отчетности. Функция, показанная выше, является частью пакета базы данных OFSA с именем OFSA_RATES и может использоваться для мультивалютной отчетности.
Функция Convert_Balance(Balance, From_Currency, To_Currency, Effective_Date) использует в качестве входного значения Balance, который необходимо конвертировать, кроме того, необходимо задать следующие параметры: From_Currency (валюта счета), To_Currency (требуемая валюта) и Effective_Date (фактическая дата).
Примечание 2. В колонке Rate_Bal определяется произведение процентной ставки на остаток. Это необходимо для вычисления средневзвешенной процентной ставки по формуле:
Pav = ( V 1 x P 1 + V 2 x P 2 + ... + Vn x Pn) : (V1 + V2 + ... + Vn), где
• V1, V2, ..., Vn - объем по n-й сделке;
• P1, P2, ..., Pn - номинальная процентная ставка по n-й сделке.
Примечание 3. В колонке Srok_Bal определяется произведение срока сделки на остаток, что необходимо для вычисления средневзвешенного срока, отнесенного к данной группе срочности по формуле:
T = (V1 x T1 + V2 x T2 + ... + Vn x Tn) : (V1 + V2 + ... + Vn), где
• V1, V2, ..., Vn - объем по n-й сделке;
• T1, T2, ..., Tn - срок по договору в пределах отчетного периода по n-й сделке.
- Агрегирование и детализация данных – продолжение.
Следующим шагом на пути получения более детализированной информации является дашборд 2. В этом случае источником информации является конкретная таблица финансового инструмента (в данном случае CONSUMER _ LOAN ) и набор соответствующих справочников.
|
Дашборд 2. Потребительские кредиты. |
Данные отчета агрегируются по следующим показателям «боковика»:
- Продукт – Код продукта финансового инструмента
- IRC – Код процентной ставки
- Амортиз. – Код типа амортизации основной суммы и процентов
- Срок – Срочность в днях
- Статус – Статус кредита
Все расчетные показатели, кроме «Кол-во сделок», являются или процентами (правило агрегации - средние значение) или остатками (правило агрегации - сумма). Желтым цветом подсвечены колонки, значения которых вычисляются системой OFSA , колонка «Рыночная стоимость» задается в процентах и определяется следующей формулой 100%*«Рыночная стоимость» / «Текущий чистый номинальный остаток». Подобные дашборды можно спроектировать для каждого финансового инструмента, дополняя их специфическими показателями для агрегации, например для «Ипотеки» можно добавить показатель «Цель кредита».
Следующим шагом для получения детализированной информации будет отображение данных в разрезе непосредственно сделок или счетов. Система позволяет настроить навигацию дашборда таким образом, что щелчок мышью по заголовку соответствующей колонки (или значению колонки) позволяет выйти на отображение требуемого запроса или дашборд, таким образом можно добраться до необходимой в данном контексте информации. В общем случае, вся линейка аналитических отчетов типа «агрегация/детализация» может быть организованна в виде связанного списка. Определенные таким образом колонки (Column Heading Interaction) выделяются цветом, а при подведении курсора выделяются подчеркиванием. В заголовке боковика таким образом (цветом) выделены «Продукт», « IRC », «Амортиз» и «Статус», и курсор позиционирован на последнем поле, что при левом щелчке мыши приводит к переходу на соответствующий справочник.
Отчет в левой части дашборда демонстрирует некоторые возможности условного форматирования, см. колонки «Статус» и «Рыночная стоимость в %». Следует особо выделить удобный и интуитивно понятный интерфейс BI EE, в качестве примера демонстрируется вкладка условного форматирования для колонки рыночной стоимости, все понятно и без комментариев. |
|
- Демонстрационная модель – настройки.
Оба показанных дашборда отображали текущее состояние банковской информации, теперь интересно продемонстрировать значения финансовых элементов в будущих периодах и соответствующие возможности визуализации и анализа. В этом случае важно влияние таких компонент системы как: прогнозные ставки, новый бизнес, предположения о поведении клиента и др.
Для демонстрации используется модель со следующими основными параметрами:
- Вычисление финансовых элементов
• Market Value – задается расчет только основных финансовых элементов
• Discount Rate ID – задан
- Предположение процентой ставки
• Forecast Rate ID – задан
• Продукт (Счет)/Филиал/Валюта
• Выборка записей финансового инструмента «Потребительские Кредиты»
Таким образом, для простоты и наглядности в модель включены только Discount Rates ID и Forecast Rates ID и не используются такие компоненты, как новый бизнес, допущения по предварительным платежам и др.
|
Дашборд 3. Discount Rates ID |
В нижнем правом углу дашборда вставлен фрагмент экранной формы Discount Rate ID (о некоторых объектах, которые можно вставлять в дашборд, будет кратко сказано ниже, раздел 7). Слева располагается информация FDM, описывающая методы дисконтирования для кэш‑флоу.
Вверху расположены таблица, отображающая значения (процентные ставки) выбранной IRC и значения процентной ставки для моделирования, а также соответствующие графики.
|
Дашборд 4. Forecast Rates ID |
На этом дашборде, слева, расположена таблица, отображающая прогнозные значения (процентные ставки) на 1, 6 и 12 месяцев выбранной IRC ( US Treasury Curve ) и значения текущей процентной ставки, а справа приводятся четыре соответствующих графика. В качестве метода для прогнозирования ставки выбран метод « Structured Change ».
- Демонстрационная модель – результаты.
На дашборде 2 видно, что записи финансового инструмента «Потребительские кредиты» в части счета « Student Loans » и филиала 102 содержат в колонке IRC (Interest_Rate_Cd) код индекса, с помощью которого регулируемая процентная ставка ( adjustable rate ) связывается с записью финансового инструмента. Если код IRC в финансовом инструменте не равен нулю, то расчет некоторых значений финансовых элементов базируется не на значении колонки Cur_Net_Rate финансового инструмента, а на значении процентной ставки, соответствующей коду IRC. Значение такой процентной ставки периодически изменяется, поэтому соответствующие платежи могут увеличиваться или уменьшаться.
В Forecast Rates ID для рассматриваемой демонстрационной модели было определено два сценария:
- Сценарий 1 – расчет по US Treasury Curve без прогнозирования – сплошная кривая на предыдущем дашборде
- Сценарий 2 - расчет по US Treasury Curve с прогнозированием – группа пунктирных кривых на предыдущем дашборде.
|
Дашборд 5. Результаты моделирования. |
В таблице представлены расчеты по некоторым финансовым элементам:
- 60 - Входящий остаток
- 210 - Основная сумма
- 430 - Процентный кэш-флоу
В качестве горизонта прогнозирования задан ближайший год, и расчеты приведены для двух сценариев. На графике отображаются данные обоих сценариев для финансового элемента «Процентный кэш-флоу» и текущая Treasury Curve .
- Некоторые возможности.
Данная статья ни в коей степени не посвящена возможностям набора продуктов бизнес анализа BI EE , здесь просто демонстрируются примеры отчетов, которые можно получить, используя эту систему совместно с финансовым хранилищем данных OFSA FDM . Но, чтобы избежать естественных вопросов, появление которых неизбежно у специалистов-практиков, некоторые возможности продукта при первом его рассмотрении должны быть представлены.
1) Представление, показанное на схеме 1, может объединять сотни тысяч и даже миллионы записей и, конечно, сразу возникнет проблема скорости. Использование в BI EE агрегированных таблиц ( aggregate tables ) является обычной техникой для улучшения сокращения времени ответа на запрос. Агрегированные таблицы содержат вычисленные заранее суммарные данные. Намного быстрее получить результат на агрегированной таблице, чем повторно обрабатывать огромное количество детальных данных. Oracle BI Server использует агрегированные таблицы автоматически, если они были должным образом определены в репозитории.
2) BI EE позволяет формировать контент дашборда, не только используя репозиторий, где хранится бизнес-модель данных, но и непосредственно. Для этого можно использовать такие объекты дашборда, как « Link or Image », « Text », « Embedded Content », что позволяет определять в рамках дашборда графические файлы, таблицы и графики Excel , произвольный текст, Web -сайты и др.
Ранее на дашборде 3, в нижнем правом углу определен графический файл с экранной формой Discount Rate ID , ниже будет продемонстрирован пример с картографической информацией. Следующий дашборд состоит из двух частей: отчета, сформированного по данным конкретного Forecast Rates Id на основе бизнес модели репозитория, и Web -сайт известного банка, где опубликованы прогнозные курсы валют.
|
Дашборд 6. Прогнозирование обменных курсов. |
Таблица в левой части дашборда показывает результаты прогноза валютных курсов с помощью Forecast Rates ID , а правая часть дашборда отображает Web -сайт, где можно найти прогнозные валютные курсы и сравнить результаты.
- Пример отображения VAR .
В рассматриваемой стохастической модели портфель формируется из двух составляющих:
- Ипотечные кредиты
- Срочные депозиты.
Числовые результаты расчета и графики отображаются на следующем дашборде:
|
Дашборд 7. VAR портфеля. |
Результирующий V a R портфеля не всегда равен сумме VaR отдельных инструментов портфеля, то есть значение V a R совокупной позиции, как правило, меньше суммы значений V a R, рассчитанных по составляющим позиции (например, для ипотеки и срочных депозитов), из-за корреляции между ипотеками и срочными депозитами. Действительно, неблагоприятное изменение котировок по одному инструменту может в определенной степени компенсироваться благоприятным изменением по другому инструменту, что уменьшает риск совокупной позиции, что видно на дашборде.
В общем случае, поскольку котировки компонент портфеля не двигаются в одном направлении и с одинаковой скоростью, то даже обычная диверсификация приводит к снижению VaR целого портфеля, т.е. VaR портфель будет меньше чем, сумма отдельных компонент.
- Использование картографических данных.
В данном разделе приводится пример сравнительного анализа по регионам. Стержнем, служащим для объединения необходимой информации, выступает иерархическая структура « Organizational Unit » , подобный пример структуры можно найти в демонстрационной БД.
|
Используя «Tree Rollup ID» формируется иерархия - листьями иерархии являются конкретные филиалы, в качестве узлов выступают географические регионы, разного уровня. В данном случае, собственно, банк выступает узлом верхнего уровня, узлом следующего уровня является область (край, республика), наконец, в рамках области выделяются регионы для экономического анализа. Конечно, данную иерархию можно изменить - ввести еще один узел для экономического района ( Центральный , Центрально-Чернозёмный , Восточно-Сибирский , Уральский и т.д.). |
Технологии Oracle предлагают способ хранения и обработки пространственных данных, в т.ч. и картографических данных, при помощи следующих компонентов: Oracle Spatial, Oracle MapViewer, Oracle Locator. Но в данном случае используются стандартные возможности HTML , когда выделенные области на карте чувствительны к нажатию кнопки мыши. На дашборде используется карта Московской области, все районы области группируются в следующие пять регионов для сравнительного анализа: ближнее Подмосковье, и четыре региона по частям света.
|
Дашборд 8. Сравнительный анализ по регионам. |
Отдельно следует сказать о таблице в левом верхнем углу дашборда - все данные, за исключением колонки «ПЛАН», выбираются из таблицы финансового инструмента Term _ Deposits , а плановые данные можно подключить несколькими способами. При использовании модуля Budgeting & Planning, эти данные можно найти в таблице Ledger _ Stat , а если плановые данные формируются иначе, то можно воспользоваться возможностью BI Enterprise Edition работать в гетерогенной среде. Т.е. плановые данные можно получить из другой системы и даже из . xls файла и объединить с фактическими данными.
При нажатии кнопкой мыши на один из пяти регионов можно перейти на дашборд (или группу связанных дашбордов), с более детальной информацией по филиалам и дополнительным офисам, или перейти на детализацию какого-либо показателя. Например, прототип следующего отчета взят из книги Е.Б. Ширинской |
|
«Операции коммерческих банков и зарубежный опыт».
- Заключение.
Подготовка отчётности занимает особое место в деятельности любого финансового института, что связано и с пристальным вниманием ЦБ РФ, и с постоянным изменением правил бухгалтерского учета (яркий пример - Положение 302-П), и с переходом на международную систему финансовой отчетности. Все это требует значительных ресурсов, и трудно рассчитывать на изменение ситуации в ближайшем будущем. Следует также учитывать, что объём информации, используемой для получения отчётов, со временем растёт, а банки часто интересуют отчёты за прошлые периоды, что станет еще более актуальным с внедрением МСФО (очень часто отчеты носят сравнительный характер, например, сравнительный баланс).
Наличие в финансовой организации нескольких жестко разделенных отчетных систем, включающих:
- обязательную отчетность ЦБ РФ
- отчетность МСФО
- аналитическую отчетность
- управленческую отчетность
причем, зачастую от разных производителей программных продуктов, не только приводит к увеличению накладных расходов, но и не позволяет выполнить элементарный анализ, особенно, если требуется сквозной анализ данных или сравнение данных из разных систем.
Предлагаемые продукты ( BI EE и OFSA ) и технологии (см. пример в разделах 1 и 2) позволяют перейти на новый технологический уровень как при формировании обязательной и аналитической отчетности, так и при получении нерегламентированных запросов.
|
