Хранилищ данных с многолетней историей в России не так уж много, практика их эксплуатации и развития представляет большой интерес. Об основных итогах шести лет построения хранилища и развития на его основе BI‑средств рассказывает вице-президент, директор департамента информационных технологий «Еврофинанс Моснарбанка» Марат Хайретдинов.

Intelligent Enterprise: Каковы основные результаты вашей многолетней работы по построению хранилища данных?

Марат Хайретдинов: Ос­но­ва всего — сами данные, их качество и актуальность. Вся бухгалтерская информация у нас загружается в хранилище, и утром уже доступна для анализа вся информация из транзакционных систем за вчерашний день. Большая часть информации по сделкам также выгружается в хранилище, но еще не вся. Когда мы обеспечим попадание в ХД данных по всем сделкам, автоматически можно будет получать окончательную отчетность по ним, и это входит в наши ближайшие планы.

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

Тем не менее автоматизация заполнения ХД данными происходит с учетом экономической целесообразности. Мы не ставим целью автоматизировать все любой ценой. Часть регистров в хранилище вводится вручную по результатам расчетов в других системах, часть — это совсем простые регистры, например «остаток на счете». В ряде случаев налоговикам проще ввести данные в определенные ячейки самим, чем разводить вокруг этого какую‑то автоматизацию. В целом отдел налоговой отчетности доволен, и перспектив развития в этом направлении осталось не так много. В этом году на базе хранилища данных мы собираемся уже полностью готовить налоговую декларацию. Этот проект, который мы, по сути дела, завершили, позволил повысить эффективность работы сотрудников. За счет автоматизации подготовки отчетности мы получили дополнительный внутренний ресурс в виде освободившегося рабочего времени. Отчасти и по этой причине незначительная оптимизация численности, которую провел банк в прошлом году, никак не отразилась на работе подразделений.

В ИТ‑департаменте мы также ведем внутренний учет расходов, и те данные, что были получены в хранилище, практически совпали с нашими внутренними результатами. Любому руководителю ИТ-подразделения известно, что правильно разнести по бюджету счета ИТ весьма непросто. Мы считаем это своего рода прорывом.

В вашем банке управленческая отчетность на базе хранилища развита значительно сильней, чем обязательная. В большинстве других известных проектов — наоборот. Почему?

Явной тенденцией последнего времени можно считать стремление делать на основе хранилищ в первую очередь регулярную отчетность. Мы же начинали именно с управленческой, поэтому, естественно, эта часть у нас развита значительно сильней. Мы с самого начала, конечно, держали в голове, что хранилище является источником для любой отчетности, но не это было основным мотивом развития проекта. Тогда, в 2003 г., возникли проблемы у наших аналитиков, которые использовали систему OFA, Oracle Financial Analyser, которую поддерживал и развивал один-единственный специалист. Когда вендор прекратил поддержку продукта, а сотрудник решил сменить работу, аналитики оказались в сложном положении и стали искать решение более надежное и универсальное, в том числе с точки зрения поддержки и развития. Кроме того, тогда остро стояла задача автоматизации подготовки международной финансовой отчетности. Мы ее, правда, до сих пор не сделали на хранилище, поскольку приоритет этой задачи впоследствии был понижен. Даже загрузка данных по сделкам в начале проекта планировалась с целью формирования управленческой отчетности.

Хранилище развивалось следующим образом. В 2004 г. началось внедрение хранилища данных на основе продукта «Контур Корпорация», через год были запущены его модули «Главная книга» и «Управленческий учет», началась работа над налоговой отчетностью. В 2006 г. появился модуль «Портфель сделок», в 2007 — «Бюджет хозяйственных расходов», в 2008 — обязательная отчетность по РПБУ, переход с 32‑разрядного сервера на 64‑разрядный. В 2009 г. сделано формирование Реестра вкладчиков по требованиям ГК «Агентство по страхованию вкладов». Формирование реестра и ранее также осуществлялось на базе информации из хранилища данных, но «на коленке». Теперь работа автоматизирована, есть отдельное приложение, и оно интегрировано с хранилищем.

С какими трудностями вы столкнулись при внедрении ХД?

Основная проблема создания хранилищ — непонимание функциональными подразделениями — потенциальными заказчиками системы необходимости создания ХД, а также непонимание ими, зачем это нужно, что это такое. Очень важно дробить проект на этапы, по результатам завершения которых можно отчитываться. И на каждом этапе у проекта должен быть спонсор от заказчика. Все это важно и с точки зрения имиджа ИТ, и с точки зрения удовлетворения потребностей заказчика. На объяснения, внутренний PR такого проекта ИТ‑службе необходимо тратить и время, и усилия, причем регулярно. У нас эта проблема уже решена, уже никто не обсуждает, необходимо ХД банку или нет. На базе ХД формируются сотни отчетов.

Как кризис сказался на ваших BI-проектах?

Отчасти благодаря нашей предусмотрительности, а отчасти благодаря случайности на пороге кризиса мы имели весь набор ИТ-инструментов, которые позволяют в кризис выживать, не только хранилище. Оно на тот момент было уже совершенно боеспособным и готовым решать любые задачи. Уже накопили опыт специалисты, которые его обслуживают, и мы уже начали пользоваться Oracle BI, который дал нам дополнительные возможности по сравнению с OLAP‑средствами «Контур BI». Внедрение BI шло в 2009 г. Мы решили выбрать его, опираясь на рекомендации Intersoft Lab, производителя нашего базового продукта для хранилища.

Довольно странно, учитывая, что вы уже используете аналогичный продукт?

Во-первых, нет предела совершенству. Во-вторых, мы пока не отказываемся от используемой нами аналитической платформы. В-третьих, Oracle BI всего лишь средство визуализации. На мой взгляд, сила Intersoft Lab не в том, что они написали какую‑то систему для создания хранилищ, а в том, что они понимают, как надо строить хранилища в России, для наших реальных задач. У них есть целостная модель построения хранилища. У всех поставщиков элементы таких моделей есть, но в таком масштабе, как у Intersoft Lab, я их ни у кого не видел. Кроме того, доступ к данной методической модели осуществляется через удобный Web-интерфейс, в который включены все отчеты, которые могут быть построены на базе ХД. И по всем отчетам расписано все, что нужно сделать, чтобы их сформировать, какие данные для этого нужны, как они должны быть обработаны. С таким инструментом можно в принципе решать любые задачи, причем решать правильно с самого начала.

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

Я‑то, общаясь с Intersoft Lab, думал, что они, рассказывая о своей модели, имеют в виду только обязательную отчетность, а оказывается, у них есть и полная методика управленческой отчетности. Их методическая модель содержит описание алгоритмов, позволяющих строить большое количество отчетов.

Но почему все же был выбран именно Oracle BI?

Дело в том, что третья версия Intersoft Lab хранилища работает уже на Oracle. Миграция на эту платформу с уже используемой версии на базе MS SQL для нас — дело сложное и долгое, это, по сути, создание нового хранилища. И оно оправданно только в том случае, если средство, которое уже применяется в организации, не справляется с существующими объемами данных. У нас это не так, поэтому и мигрировать на новую версию мы пока не собираемся.

А Oracle BI — ему все равно, с чем работать, с какой базой. Он достаточно удобен и дает пользователю возможность делать кубики OLAP, которые ему необходимы. Не любому пользователю, конечно, а достаточно квалифицированному, уровня аналитика или продвинутого в части ИТ сотрудника банка. Во всяком случае, с помощью BI мы можем довольно быстро создавать новые отчеты. Самая большая проблема, как и раньше, — загрузка данных, которых пока нет в прикладных системах. Поэтому сейчас мы идем по пути выгрузки информации, необходимой для создания того или иного отчета, расчета того или иного норматива. Если нужны данные для расчета, а их нет ни в одной прикладной системе банка, то мы либо вводим эти данные в ХД руками, либо автоматизируем оформление той операции/сделки, данные по которой необходимы в ХД, а уже затем автоматизируем выгрузку этих данных в ХД. Все это непросто, требует усилий, времени, денег.

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

Каковы ваши дальнейшие планы развития BI-инструментов?

Мы собираемся идти по пути расчета нормативов и прогнозирования, моделирования, расчета вариантов «а что, если…». Хотим попробовать на одном нормативе, наиболее важном, а потом распространить полученную технологию на все остальные. Это и есть перспектива для нас. Понятно, что все время требуются новые отчетные формы, но концептуально хочется решить задачу моделирования и прогноза, чтобы понимать, к каким последствиям приводят те или иные действия на различных рынках, как это может отразиться на отчетности и на значениях нормативов. Сейчас говорить о стратегическом развитии трудно. То, что можно бы было сделать быстро чужими руками, мы, будучи вынуждены меньше привлекать внешних исполнителей, постепенно делаем своими силами, оттачивая методологию. Например, налоговая отчетность. Кубиков уже много, все работает, но нужно сложить их в единую мозаику, чтобы появилась единая работающая система — общая картина.

Мы постоянно стараемся оптимизировать производительность ХД. В частности, при анализе управленческой отчетности выяснилось, что для анализа используется очень глубокая детализация. Чтобы снизить нагрузку на систему, можно объединить аналитические записи по группам лицевых счетов, не ухудшая качества формируемой отчетности. Пока это не сделано, но мы обсуждаем такие возможности с функциональными подразделениями. Это богатый внутренний ресурс, используя который, можно в разы поднять производительность.

И еще одно направление — более активное использование ХД филиалами. Пока еще не все филиалы используют все прелести уже созданной отчетной базы, они работают с хранилищем не так активно, как головной офис. В филиалах используются не все системы, которые есть в центре. Стоит задача перевести в промышленную эксплуатацию в регионах те системы, которые там пока используются ограниченно. Мы продолжаем свою работу по унификации всех используемых систем. В частности, мы плани­руем наладить в филиалах выгрузку всей необходимой информации для формирования налоговых регистров. Механизмы для этого есть, требуется организационная работа, которая позволит высвободить дополнительные ресурсы.