Хранилище для МСФО

На российском банковском рынке бум спроса на хранилища баз данных пришелся на прошлый год. Большинство банков, которые имели весьма смутное представление об этих системах, были поставлены перед необходимостью их внедрения из-за перехода на отчетность по МСФО. Как говорит руководитель проекта «Нострадамус» компании «ПрограмБанк» Дмитрий Осиновский, «переход на международные стандарты финансовой отчетности подстегнул интерес банков к хранилищам баз данных. Если раньше потребность банков в получении внешней отчетности удовлетворялась наличием АБС, то теперь, в связи с переходом на международные стандарты финансовой отчетности, финансовые институты почувствовали необходимость инвестировать средства в заказные, индивидуальные решения». По мнению руководителя проекта «Хранилище данных» компании «ФОРС-Банковские Системы» Дмитрия Косова, переход на международные стандарты бухгалтерской отчетности в идеале требовал от банков полной замены существующего программного обеспечения. К полной замене, скорее всего, не готов никто, говорит Д. Косов, поскольку стоимость такого мероприятия окажется чрезмерно велика почти для любого банка. Поэтому хранилища данных стали определенным компромиссом — пристройкой, не нарушающей устоявшейся работы банка. Впрочем, по мнению директора по маркетингу компании Intersoft Lab Юлии Амириди, «сказать, что переход банков на МСФО привел к росту числа внедрений хранилищ данных, нельзя, скорее, спрос на рынке сформировался, и теперь количество внедрений постоянно увеличивается».

Проводки «задним числом» — конкурентное преимущество

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

Во-первых, для большинства банков, как было уже сказано, интерес к внедрению хранилищ баз данных связан, прежде всего, с переходом на МСФО. Поэтому одной из главных задач этих систем в приложении именно к отечественному рынку является собственно подготовка отчетности по международным стандартам: либо параллельной, либо преобразованной из традиционной бухгалтерской (см. «БО» № 3, «Трансформация или двойной учет?»).

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

И, в-третьих, для российских банков принципиально важно наличие в системе возможности заносить или исправлять данные «задним» числом. Как заявил «БО» коммерческий директор департамента аналитических систем R-Style Softlab Юлий Гольдберг, зарубежные банки работают в текущем дне, и, если в учете происходят какие-то изменения, то это делается посредством ввода сторнирующих проводок. В системах, предназначенных для российского рынка, необходимо предусмотреть возможность изменять архивные данные «задним» числом. С этим соглашается Дмитрий Осиновский («ПрограмБанк»): «Это наша норма, а не исключение из правил — в противовес западному, классическому представлению о хранилище данных как о неком идеальном месте, где данные только пополняются и никогда не изменяются».

Прибыли банка зависят от качества анализа

Кроме создания отчетности по МСФО банки используют хранилища баз данных и непосредственно для проведения анализа собственной деятельности. По мнению Юлия Гольдберга (R-Style Softlab), речь идет о задачах учета и контроля бюджета: «Основная цель, которую преследуют банки, внедряющие системы хранилища баз данных, — это сбор и последующий анализ информации, необходимой для получения целостной картины состояния бизнеса».

Как отмечает Дмитрий Косов («ФОРС-Банковские Системы»), после достаточно продолжительного периода практически тепличного роста банков наступил момент, когда прибыль, полученная от бизнеса, в гораздо большей степени зависит от правильности и своевременности принятых управленческих решений и, соответственно, от качества проведенного анализа. Банки в условиях роста конкуренции и развития клиентской базы, в первую очередь за счет роста розничных проектов, просто вынуждены развивать аналитические приложения, поскольку рост объемов данных, необходимых для проведения полноценного анализа, превышает возможности человека. Те, кто понимает, что временные решения, вроде использования электронных таблиц, только отодвигают сроки принятия решения о создании полноценной аналитической системы, уже сейчас переходят к ее построению, а аналитические системы лучше всего реализуются на хранилищах баз данных.

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

Юлия Амириди (Intersoft Lab) сравнивает внедрение хранилищ бызы данных с первым этапом создания внутри банков комплексных BPM-решений (Business Performance Management — управление эффективностью бизнеса). Пока с его помощью российские банки начинают решать отдельные управленческие задачи, говорит она. Со временем набор функций хранилищ будет расширяться. Кроме того, есть еще одно немаловажное обстоятельство, имеющее отношение уже не к бизнес-задачам банка, а к его информационной стратегии. Для многих банков хранилища данных — еще один способ решения проблемы «лоскутного одеяла». Иначе говоря, проблемы интеграции разрозненных технических решений в области учетных систем, накопленных за время развития банка.

Очевидно, что большинство учетных систем, в том числе АБС, всевозможные CRM, модули учета ценных бумаг и т.п., разрабатываются под решение конкретной потребности банка в ПО и слабо согласуются с другими бизнес-процессами. Получается, что в банке присутствует множество «вещей в себе», «связывать» которые между собой приходится в том числе и хранилищу данных.

Именно поэтому одной из наиболее актуальных проблем для отечественных разработчиков хранилищ данных остается необходимость наличия опции ручного ввода и редактирования. Популярность этой опции связана с тем, что во многих банках — особенно имеющих филиалы — есть ряд направлений бизнеса, важных для учета, но слишком «маленьких» для автоматизации (по ним выполняется порядка 10 операций в месяц). В таких случаях необходимые данные часто учитываются не средствами АБС, а средствами Microsoft Excel. Кроме того, с переходом на международные стандарты финансовой отчетности появилась потребность в новых данных, которые невозможно получить из АБС, ведущих учет по РПБУ. Соответственно, для их сбора также необходим модуль ручного ввода. Поэтому все отечественные разработчики предлагают особые средства ручного ввода в поставляемых хранилищах данных. Например, в решении компании «ПрограмБанк» это специализированный модуль ручного ввода, который может быть легко настроен на ввод любых данных путем описания шаблонов ввода. Хотя модуль и обладает похожим на Microsoft Excel интерфейсом, он лишен его недостатков: пользователь не сможет испортить формат или ввести неклассифицированные значения, проводится первичная проверка вводимых данных на согласованность, нет ограничений на размер файла и т.д.

Хранилище как способ управления филиалами

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

Например, в банке «Петрокоммерц» до последнего времени действовала собственная система сбора, хранения и анализа данных. Но поскольку банк является многофилиальным, перед ним встала проблема стандартизации потоков данных, поступающих из регионов.

За счет внедрения «профессионального» хранилища базы данных «от разработчика» «Петрокоммерц» решил, например, задачу формирования единой отчетности с филиалами. Как известно, предоставляя отчетность в контролирующие органы, многофилиальные банки работают по единой технологии: филиалы сдают собственную отчетность в региональные подразделения Банка России, а головной офис одновременно передает консолидированную отчетность, включающую в себя данные филиалов. В ситуации, когда филиалы используют автономные АБС (а так бывает в подавляющем большинстве случаев), трудно обеспечить идентичность данных в отчетах филиалов и в консолидированной отчетности.

Чтобы удовлетворить запросы именно многофилиальных банков, разработчики отечественных систем обеспечивают поддержку бизнеса «территориально распределенных финансовых структур». В таком случае рабочие места сотрудников, ответственных за ввод данных по направлению, могут располагаться не только в головном офисе, но и непосредственно на местах, в подразделениях, отвечающих за соответствующий сегмент. «Это удобно, — говорит Юлий Гольдберг (R-Style Softlab), — и некоторые банки, наши клиенты, намерены даже отказаться от собственных бэк-офисов, используя RS-DataHouse в качестве основного средства автоматизации ряда бизнес-направлений в филиалах».

Помимо расширения функционала хранилищ разработчики начинают работать и над тем, чтобы сделать их максимально понятными, удобными именно для конечных пользователей и специалистов, которые «наполняют» их данными. Например, «ПрограмБанк» даже начал разработку, позволяющую оформлять финальную консолидацию и отчетность, в том числе и по МСФО, в виде файла Microsoft Word.

Новости информационных технологий в банках

«Диасофт» объявила результаты развития 5NT (e) TREASURY в 2004 году

Компания «Диасофт» объявила о результатах развития решения для работы на финансовых рынках 5NT (e) TREASURY за 2004 год.

Доходы компании по этому направлению составили 3,8 млн долларов. Такие показатели, в первую очередь, обусловлены большим числом клиентов (систему используют в головных офисах 126 банков и 16 компаний), а также активным развитием бизнеса банков, инвестиционных и управляющих компаний на данном сегменте рынка.

В течение 2004 года в составе 5NT(e) TREASURY разработан ряд новых программных модулей и внесено несколько сотен функциональных доработок в уже существующие. В частности, разработаны новые модули налогового учета операций с ценными бумагами и учета сделок на срочном валютном рынке (forward, option), в разработке находятся модули управления пулами и управления рисками. В бэк-офисных модулях появились операции мены и займа ценных бумаг, отмены второй части сделки РЕПО и Margin Call. Произошли интерфейсные преобразования сделок РЕПО, поручений на кастодиальные операции. Был проведен реинжениринг технологии работы с векселями. В БзЮмодуле учета операций банковского доверительного управления реализован внутренний учет денежных средств, находящихся в доверительном управлении. Расширены возможности взаимодействия с внешними системами: теперь на ММВБ поддерживается работа с заявками в РПС и на сделки РЕПО, разработаны поручения на клиринг для работы с ЦЭД РТС.

На 2005 год запланировано дальнейшее развитие системы 5NT(e) TREASURY в направлении решения управленческих задач, планируется также дальнейшее расширение спектра функциональных возможностей бэк-офиса.

АБС не справляется с анализом

Часто хранилище данных воспринимают просто как большую, очень большую базу данных. На самом деле хранилище данных — сложная комплексная система, в которой база данных является лишь одной из составных частей. Кроме базы данных хранилище включает в себя сложную инфраструктуру: средства изменения и расширения базы данных, технологию регулярного сбора данных, инструменты проверки и очистки данных, технологию ввода и изменения аналитических признаков, расчета показателей и консолидации данных, инструменты выполнения запросов, создания отчетов и анализа в режиме реального времени, технологию построения сложных отчетов, средства разграничения прав доступа и тому подобное. Можно сказать, что главная цель любого хранилища данных — именно интерпретация и анализ информации. А сбор и сохранение информации — лишь одна из задач.

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

Чтобы собирать и анализировать информацию, требуется специализированная структура базы данных, поэтому аксиомой для специалистов стало то, что построить полноценную аналитическую систему на базе обычной АБС невозможно.

Разделение информации и функциональных задач между АБС и хранилищем данных позволяет сразу «убить двух зайцев»: с одной стороны, уменьшить объем, увеличить скорость работы и упростить администрирование, а с другой — значительно повысить эффективность работы аналитических приложений и облегчить получение оперативной и всесторонней информации. Строго говоря, АБС предназначены для быстрого ввода, а не для быстрого извлечения данных, поэтому в результате аналитики получат медленно работающие отчеты, а операционисты — затруднения в работе в момент выпуска отчетов. Ведь в основе АБС чаще всего лежат так называемые OLTP-системы, основная цель которых — быстрое выполнение большого количества коротких однотипных транзакций в режиме реального времени (On-Line Transaction Processing — оперативная обработка транзакций). Применительно к сфере банковских технологий такие системы ориентированы на эффективное выполнение ограниченного набора операций, например открытие счета, просмотр спецификации к нему и т.д.

Чтобы решить эту проблему, в начале 90-х годов специалист в области создания баз данных большого масштаба У. Инмон предложил новую форму организации информационных структур в виде предметно-ориентированного, интегрированного, неизменчивого, поддерживающего хронологию набора данных, организованного с целью поддержки управления. Системы такого типа собственно и получили название «Хранилище данных» (Data Warehouse).

Следующим этапом создания хранилищ данных стало создание OLAP-технологии. Одна из основных проблем при проведении анализа тех или иных данных — максимальная оперативность. Время руководителей и аналитиков банка стоит особенно дорого, и каждая минута, проведенная в ожидании ответа системы на полученный вопрос, сокращает преимущество ее использования. Поэтому высокая скорость выполнения аналитических запросов стала главной целью разработчиков OLAP-технологии оперативного анализа данных (On-Line Analytical Processing). Этот термин объединяет программное обеспечение, предоставляющее пользователю возможность мгновенно, в режиме реального времени получать ответы на произвольные аналитические запросы.

Читайте так же материалы по теме Хранилище базы данных для сферы банковских услуг:

1. Готовых хранилищ баз данных на рынке нет

2. Сокровищница для банковских данных