2004 г.

Практический опыт применения OLAP для подготовки и дистрибуции управленческой отчетности в АКИБ "УкрСибБанк"

Радченко О.Н. - начальник отдела сопровождения Управления методологии работы банка АКИБ "УкрСибБанк", Украина, г. Харьков
Опубликовано: "Банки и технологии", 2003, №3
Intersoft Lab

Использование OLAP-технологии для подготовки управленческой отчетности в АКИБ "УкрСибБанк" началось в ходе работ по внедрению финансового хранилища данных "Контур Корпорация". Собственно говоря, возможность получать отчетность в виде OLAP объектов и была одним из оснований выбора "Контур Корпорации" банком. Первоначально нами использовались "Контур Стандарт" (версии 3.2) редакций Developer и Runtime. Эти средства позволяли обеспечить достаточно быструю разработку и исполнение OLAP-приложений, при этом позволяя нам в значительной степени разделить процедуру создания новых отчетов между собственно программистами и аналитиками, так как после создания источника данных, обеспечивающего выборку данных, необходимых для подготовки отчета, его компоновка (включая связывание основной выборки с дополнительными - например, переклассификация отдельных показателей, входящих в отчет с помощью дополнительных справочников, добавление к отчету новых показателей, получаемых из дополнительных источников данных) могут с помощью средств "Контур Стандарт" Developer осуществляться аналитиками, а не непосредственно программистами. Подготовленные аналитиками OLAP-приложения с помощью "Контур Стандарт" Runtime выполнялись сотрудниками банка, обеспечивающими выпуск управленческой отчетности, в результате чего они получали кубы, каждый из которых заменял сразу несколько отчетов за счет возможности трансформации куба через пользовательский интерфейс. После ввода в эксплуатацию модуля "Бюджет" имеющийся набор отчетов быстро дополнился отчетами по мониторингу выполнении бизнес - планов.

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

Однако, после полугодовой эксплуатации системы управленческой отчетности, выпускавшейся на основании данных, собираемых системой "Контур-Корпорация", с помощью программных средств "Контур-Стандарт" мы столкнулись с проблемами, знакомыми, наверное всем ИТ-специалистам, занимающимся сопровождением систем подготовки отчетности: чем более функциональной становится такая система, тем более ресурсоемким становится ее сопровождение…

Проблемы заключались в том, что средства "Контур-Стандарт", которыми мы пользовались, работали только с "живыми" кубами (т.е. кубами, которые после получения нельзя было сохранить), и, таким образом, каждый из работников банка, которому были необходимы данные, должен был запустить хранимую процедуру, извлекающую их, дождаться ее выполнения на сервере, получить необходимый OLAP-объект (куб), провести его анализ, экспортировать необходимые данные для выпуска отчетов (а на основании данных, содержащихся в каждом из кубов, готовятся, как правило, несколько различных отчетных форм). Такая технология приводила к интенсивной конкуренции пользователей системы за ресурсы сервера базы данных (при этом часто одновременно выполнялось 2-3 экземпляра одной и той же хранимой процедуры с идентичным набором параметров). Вследствие этого требования к быстродействию средств извлечения данных повышались, из-за чего хранимые процедуры подвергались штучной ручной оптимизации, при этом под каждую группу пользователей создавались индивидуальные версии одинаковых по сути выборок. В результате этого модификация одного отчета начала требовать модификации целого семейства хранимых процедур.

Кроме этого, территориальное размещение подразделений банка начало накладывать жесткие ограничения на объем сетевого трафика, параллельная доставка нескольким пользователям, находящимся в одном сегменте сети, одного и того же набора данных (при этом транспортные форматы, использующиеся машинами доступа к данным, не отличаются экономностью) стала непозволительной роскошью. И пользователи начали спрашивать: "- А могу я отдать свой куб? А еще лучше было бы, если бы Вы его выпустили и прислали мне…". Спустя месяц-полтора после того, как мы услышали первый такой вопрос, была анонсирована новая серия продуктов Intersoft Lab - "Аналитическая платформа Контур", содержавшая набор инструментов, позволяющих сделать именно это.

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

Ознакомившись с функциональными характеристиками продуктов Аналитической платформы, мы пришли к заключению, что значительная часть наших проблем может быть решена за счет использования продуктов линии Контур OLAPBrowser (Аналитик и Инспектор) и Контур Генератор Кубов. Действительно, OLAPBrowser позволяет просматривать и перестраивать готовые кубы, а Генератор Кубов - выпускать их по настроенным сценариям. Для того, чтобы иметь возможность использовать ранее подготовленную отчетность, мы также сочли целесообразным использовать и новую версию Контур Стандарт (4.0), которая кроме полной поддержки отчетов старых версий Контур Стандарт, позволяет сохранять кубы в качестве отдельных файлов. Кроме того, упоминавшиеся выше инструментальные средства Контур Стандарт по визуальному конструированию отчетов на основании предварительно настроенных источников данных представляются нам весьма полезными.

Следует, наверное, более подробно рассказать о том, где и какая собственно отчетность нами выпускается. АКИБ "УкрСибБанк" за последние 5 лет совершил превращение из корпоративного банка в один из крупнейших розничных банков Украины: количество самостоятельных балансовых единиц (филиалов) увеличилось с 5 до 21, количество торговых точек в настоящее время составляет более 200. В банке сложилась матричная система управления - по территориальному признаку (по филиалам, а в последнее время и по более крупным региональным объединениям) и по бизнес - делению (индивидуальный бизнес, корпоративный бизнес, межбанковский бизнес, ценные бумаги).

В банке эксплуатируется банковская система RS-Банк, адаптированная к требованиям украинского законодательства, при этом в каждом из филиалов работает собственный экземпляр системы, консолидация данных осуществляется средствами модуля Контур Корпорация "Управление филиалами".

Центральная часть управленческой отчетности, которая готовится при помощи программных средств разработки компании Intersoft Lab, представляет собой вариации классических банковских отчетов - Баланса (который под влиянием терминологии, принятой в модуле "Бюджет" у нас чаще называется Бюджетом Активов и Пассивов, далее - БАП) и Отчета о доходах и расходах (далее - БДР, следуя той же терминологии модуля "Бюджет"), при этом сопоставляются плановые показатели для БАП и БДР (которые ведутся с помощью модуля "Бюджет") с фактическими показателями работы подразделений банка и отслеживается динамика изменения показателей за отчетный период. Планы используемых показателей детализированы до уровня бизнес - подразделений, обобщенных финансовых инструментов (национальная валюта - иностранные валюты) и ведутся в разрезе торговых точек банка. Отчеты по выполнению БАП и БДР выпускаются ежедневно - в виде рабочих сводок высшему менеджменту банка, отражающих общие результаты работы банка, еженедельно - в виде развернутых отчетов, которыми снабжаются руководители всех бизнесов и филиалов и ежемесячно - с расширенным набором показателей, отражающих общие результаты работы за месяц.

Сбор фактических данных по достижению плановых показателей осуществляется частично за счет учета на уровне лицевых счетов Главной книги (так, в частности реализовано разделение данных по торговым точкам внутри филиала), частично - за счет анализа документов (таким образом, например реализовано разбиение комиссионных доходов по видам продуктов). Кроме данных Главной книги используются дополнительные данные управленческого учета, за счет которых осуществляется внутрибанковское перераспределение доходов между подразделениями. Общее количество лицевых счетов, участвующих в формировании отчета о выполнении БАП, составляет в целом по банку более 100 тысяч, для подготовки отчета о выполнении БДР анализируется около 70 тыс. лицевых счетов и 100-120 тысяч документов.

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

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

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

Кроме этого, накопленный на первом этапе работы по созданию управленческой отчетности опыт использования OLAP-объектов (кубов Контур-Стандарт) для анализа позволил нам выработать более продуктивный подход к построению кубов. На этом аспекте проблемы хотелось бы остановиться подробнее.

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

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

В новых версиях средств выборки данных для построения отчетов мы стали использовать другую форму набора данных

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

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

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

Одновременно с унификацией источников данных была начата реализация схемы централизованного выпуска кубов с рассылкой их потребителям. Это решение было стимулировано переездом значительной части Головного банка из Харькова в Киев, при этом информационная инфраструктура продолжала работать в Харькове. Используя возможности Контур Стандарт в.4.0 (импорт настроенных отчетов из формата, использовавшегося предыдущей версией, занимает очень немного времени), старые отчеты выпускались выделенным исполнителем в Харькове, сохранялись в виде микрокубов, а затем отправлялись потребителям в г. Киев. В ходе этой работы выяснилось, что даже такое простое решение позволяет значительно снизить сетевой трафик, средний объем передаваемых данных как правило, не превышает 2-3 мегабайт в день.

По мере готовности новых, унифицированных источников данных для кубов, их выпуск переводится с ручного (через Контур Стандарт в.4.0) на автоматический с помощью еще одного программного средства, входящего в состав АПК - Контур Генератор Кубов. Это - утилита командной строки, которая создает кубы по заданным сценариям. Ее использование позволяет в значительной мере сократить необходимость в ручных работах по выпуску кубов. При использовании этого средства мы пришли к заключению, что рекомендуемый разработчиками путь его использования - создание предварительно настроенных файлов сценариев не является достаточно гибким для реализации всех потребностей банка. Программная генерация сценария представляется более универсальным средством, тем более что синтаксис файлов сценариев достаточно прозрачен (это XML-файл достаточно простой структуры) и реализация такой задачи не представляется слишком сложной.

Следующим этапом внедрения OLAP-технологии для подготовки и дистрибуции управленческой отчетности будет внедрение системы распространения управленческой отчетности с помощью WEB-технологии. Мы планируем в ближайшие месяцы обеспечить публикацию готовых отчетов через Intranet - сайт с прокси - кэшированием кубов на стороне филиала (удаленной площадки банка).

Общая схема прорабатываемого решения предполагает, что сразу после генерации все регулярно выпускаемые отчеты публикуются с помощью Microsoft Internet Information Server и могут быть через WEB-интерфейс получены пользователями любого филиала (удаленной площадки) банка, при этом прокси - сервер филиала, через который работают пользователи, обеспечивает однократную доставку файлов микрокубов от IIS в сегмент сети филиала. Кроме публикации регулярно выпускаемых отчетов предполагается также реализация возможности интерактивного заказа на выпуск куба удаленным пользователем через WEB-интерфейс с заданием дополнительных параметров. Практика показывает, что при подготовке управленческой отчетности иногда возникает необходимость в подобного рода возможностях - как для расследования возникающих расхождений в отчетах, так и для получения объяснений относительно значительных изменений, произошедших за отчетный период.

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

Основными путями достижения снижения совокупной стоимости владения в отношении системы подготовки управленческой отчетности мы считаем:

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

Количественная оценка того, насколько эти ожидания банка оправдаются, пока еще дело будущего. Собственно говоря, работы по внедрению OLAP-средств Аналитической платформы Контур для подготовки и дистрибуции управленческой отчетности в АКИБ "УкрСибБанк" еще далеко не завершены. К первым реальным результатам можно отнести то, что упоминавшийся ранее централизованный выпуск кубов позволил почти в 50 раз снизить объем сетевого трафика между инфраструктурным центром банка в г. Харькове и управленческими его структурами, которые в настоящее время работают в г. Киеве. Кроме того, переход к планированию и контролю исполнения планов с детализации до уровня филиалов на уровень торговых точек оказался практически незаметным для подразделений банка, так как модификация в значительной степени унифицированного набора средств извлечения данных для подготовки управленческой отчетности оказалась намного менее трудоемкой, чем этого можно было ожидать. Трудоемкость сопровождения и развития действующей системы отчетности также характеризует то, что до настоящего времени разработка средств извлечения данных решается одним программистом при периодическом привлечении одного, максимум двух человек для решения отдельных задач.