Как помирить "автоматизаторов" и "аналитиков" при создании Хранилища данных

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

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

Цель этой статьи - обозначить позиции "аналитиков" и "автоматизаторов" и сформулировать современные требования к банковским Хранилищам данных.

Подход "аналитиков"

"Аналитики" являются заказчиками и постановщиками таких задач управления кредитной организацией, как контроллинг, cтратегическое планирование и бюджетирование, управленческий учет, управление активами/пассивами и рисками, управление клиентской базой, продажами банковских продуктов, персоналом и т.п.

Для них представляет интерес подготовка в Хранилище данных управленческой отчетности, сводной отчетности по РПБУ, отчетов по МСФО, налоговой отчетности, отчетности для Агентства по страхованию вкладов, обмен данными с Кредитным бюро.

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

Подход "автоматизаторов"

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

Основная АБС банка, бэк-офисные модули, процессинг, система автоматизации хозяйственной деятельности, CRM - вот далеко не полный список систем операционного учета, из которых должна поступать информация в Хранилище. В этих системах содержатся бизнес-данные, которые условно можно разделить на четыре вида:

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

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

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

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

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

Путь к примирению

Где же выход из сложившейся ситуации? Для решения проблемы надо разработать единый интерфейс общения "аналитиков" и "автоматизаторов". Для этого можно ввести понятие обобщенных информационных объектов Хранилища. Их наличие в Хранилище данных послужит основой для построения комплексной системы. На основе этих объектов в процессе выполнения проекта создаются реальные объекты Хранилища данных. В терминах и свойствах обобщенных объектов "аналитики" будут формулировать свои задачи, а "автоматизаторы" наполнять Хранилище данными из исходных систем и реализовывать алгоритмы обработки данных. Эта мера взаимно ограничивает в творчестве и тех, и других, заставляет скорректировать свои подходы, но служит разумным компромиссом для конструктивного диалога.

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

Рассмотрим, каким требованиям должны соответствовать объекты Хранилища для сбора и обработки самого сложного вида первичных данных - сделок.

Обобщенная сделка

Обобщенная сделка - это информационный объект Хранилища данных, обеспечивающий хранение, обработку и консолидацию разнообразных сделок:

• кредитный портфель (кредиты юридических и физических лиц);
• торговые и инвестиционные портфели ценных бумаг (государственные и корпоративные облигации, акции, торгуемые векселя и пр.);
• биржевые сделки (FX, ММ, SWAP, REPO, OPTION);
• портфели пассивов банка (депозиты, "блокировки" юридических лиц, срочные вклады физических лиц и пр.);
• собственные ценные бумаги (векселя, облигации, депозитные сертификаты и пр.);
• договора хозяйственной деятельности (аренда, основные средства, коммуникации, обучение и пр.) и т.д.

Чтобы удовлетворить двум задачам - консолидации и учету специфики каждого вида сделки, обобщенная сделка должна состоять из двух частей - постоянной и переменной.

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

Следующим важным обобщенным объектом Хранилища являются графики и потоки платежей. Каждая сделка имеет свой график выдач и погашений, получения комиссий и процентов - график платежей. График платежей может представлять собой либо фиксированные даты и суммы, либо правила, по которым определяются эти даты и суммы. Два вида хранения графика платежей необходимы для учета особенностей различных систем автоматизации, в которых обрабатываются сделки. Но Хранилище данных должно обеспечивать генерацию графика платежей в виде дат и сумм на основании правил: это необходимо для консолидации.

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

Наличие в Хранилище графиков и потоков платежей позволяет оценить сроки, динамику и расхождение планового и фактического календаря движения средств по каждой сделке, группе сделок, контрагенту или по банку в целом.

Позиционный учет сделок

Бухгалтерский учет по лицевым счетам позволяет сгруппировать на учетных регистрах суммы выполнения однородных бухгалтерских операций. Для подготовки такой бухгалтерской отчетности, как баланс, отчет о прибылях и убытках, достаточно использования значений лицевых счетов. Но для таких задач, как расчет ежедневных нормативов по Инструкции ЦБ РФ №110-И, управленческий учет доходности и рисков, подготовка налоговой отчетности и отчетности по МСФО данных только бухгалтерского учета недостаточно. Для эффективной обработки аналитической информации современное Хранилище данных должно содержать объекты управленческого учета сделок. С этой целью вводится понятие позиции. Ее аналог - лицевой счет бухгалтерского учета с оборотами и остатками по времени. Отличие позиции от лицевого счета заключается в том, что она обеспечивает выполнение одностороннего учета (отсутствует двойная запись). Состав и виды позиций регламентируются не правилами бухгалтерского учета, а задачами управленческого учета и типами сделок. Примеры позиций: основная задолженность в разрезе сроков до погашения и контрактной срочности, количество пролонгаций, размер обеспечения кредитов и т.д.

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

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

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

Для каждой операции определен свой состав позиций, по которым учитывается сделка. Операция обеспечивает однозначную связь между изменением атрибутов сделки, значениями позиций, графиков и потоков платежей.

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

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

Соответствие позиционного и бухгалтерского учета

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

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

Заключение

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

В статье были рассмотрены основные требования к Хранилищу данных только в части работы со сделками. Это далеко не все, что требуется от современного Хранилища. Существуют и другие важные задачи - формирование реестра клиентов банка, генерация производных аналитических показателей (расшифровок к отчетам по МСФО, трансфертных сделок) и т.д. Всем этим требованиям удовлетворяет новая версия системы "Контур Корпорация" разработки компании Intersoft Lab, которая в настоящее время внедряется в ряде российских банков.

Автор: В. Чаусов, Ю. Амириди

Источник: "Банковские технологии", 2006, №4