Публикации

Intersoft Lab в СМИ - истории успеха клиентов, интервью и мнения экспертов компании, обзоры рынка CPM

Технологии BI и EAI для многофилиальных банков: практическая реализация актуальных тенденций

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

Объединение технологий BI, BPM и EAI: Тенденция? Реальность!

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

Изменения претерпел не только подход к архитектуре информационной банковской системы (ИБС). В понимании банковских специалистов серьезной ревизии подверглось и само понятие ИБС. Ушло в прошлое время, когда термины ИБС и автоматизированной банковской системы (АБС) были тождественны. Современное понимание предназначения комплексной ИБС можно сформулировать как "управление активностью и эффективностью банковского бизнеса". Поэтому важнейшими составляющими ИБС, наряду с модулями для автоматизации отдельных направлений деятельности банка, стали BI-системы (Business Intelligence, бизнес-аналитика) и BPM-приложения (Business Performance Management, управление эффективностью бизнеса).

Чтобы собрать данные из специализированных учетных модулей в единое Хранилище данных для последующей обработки инструментами BPM, анализа и подготовки отчетов, используют различные технологии интеграции. Это традиционные средства ETL (Extraction, Trasformation, Loading, извлечение, преобразование, загрузка) и инструменты интеграции последнего поколения, которые опираются на технологии XML (eXtensible Markup Language, расширяемый язык разметки) и Web-сервисы.

В ноябре минувшего года Консорциум по интеграции (Integration Consortium, сокр. IC) опубликовал прогноз по рынку технологий интеграции на 2005 год. По мнению членов IC, одна из тенденций, которая будет господствовать на рынке в этом году, это объединение технологий интеграции бизнес-приложений и BI в продуктах для конечных пользователей. Фактически, речь идет о встраивании инструментов интеграции в BI(BPM)-системы.

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

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

Практический опыт: автоматизация сбора сделок в многофилиальном банке

Банк, который будет рассмотрен в примере, является типичным представителем многофилиальных кредитных организаций из числа 30 крупнейших в России. Как правило, масштаб филиальной сети таких банков от 20 до 50, в их структуру также могут входить дочерние банки. География филиальной сети может охватывать практически все регионы страны.

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

Формат и технология сбора сделок

Первым шагом в реализации проекта по сбору сделок в Хранилище банка стала разработка унифицированного формата представления данных по сделке, который содержит минимально необходимый набор информации для описания практически любой сделки: кредиты, депозиты, операции с ценными бумагами, операции MoneyMarket, FOREX, сделки REPO и т.д. Формат основного документа позиции по сделке включает 58 реквизитов, каждый из которых должен быть заполнен при выгрузке данных по договору из соответствующих систем автоматизации бек-офиса.

<?xml version="1.0" encoding="windows-1251" ?>
<?Contour version="1.2" ?>

<Сеанс>
<КонтрольныйЛистСеанса>
  <Филиал>2</Филиал>
  <Дата> 1-01-2002</Дата>
  <НомерCеанса>1</НомерCеанса>
  <КоличествоДокументов>0</КоличествоДокументов>
  <ЕстьДокументыПозднее>Нет</ЕстьДокументыПозднее>
  <КонтрольноеЗначение>0</КонтрольноеЗначение>
  <ДатаВыгрузки>24-07-2002</ДатаВыгрузки>
  <ВремяВыгрузки>19:00:01</ВремяВыгрузки>
  <ВерсияПО>1.3.01.01</ВерсияПО>
  <ДатаПервогоАрхивногоДокумента></ДатаПервогоАрхивногоДокумента>
  <КоличествоАрхивныхДокументов>0</КоличествоАрхивныхДокументов>
  <ПервоначальнаяВыгрузка>Y</ПервоначальнаяВыгрузка>
  <ПолнаяВыгрузкаСчетов>Нет</ПолнаяВыгрузкаСчетов>
  <ПолнаяВыгрузкаКлиентов>Нет</ПолнаяВыгрузкаКлиентов>
  <СтатистикаСеансаВыгрузки>
    <СтатистикаВыгрузкиОбъектов>
      <ТипОбъектов>Staff</ТипОбъектов>
      <ВсегоОбъектов>2</ВсегоОбъектов>
      <ЭкспортированоОбъектов>2</ЭкспортированоОбъектов>
    </СтатистикаВыгрузкиОбъектов>
    <СтатистикаВыгрузкиОбъектов>
      <ТипОбъектов>Subject</ТипОбъектов>
      <ВсегоОбъектов>12</ВсегоОбъектов>
      <ЭкспортированоОбъектов>12</ЭкспортированоОбъектов>
    </СтатистикаВыгрузкиОбъектов>
    <СтатистикаВыгрузкиОбъектов>
      <ТипОбъектов>Account</ТипОбъектов>
      <ВсегоОбъектов>286</ВсегоОбъектов>
      <ЭкспортированоОбъектов>282</ЭкспортированоОбъектов>
    </СтатистикаВыгрузкиОбъектов>
  </СтатистикаСеансаВыгрузки>
  <ОшибкиСеансаВыгрузки>
  </ОшибкиСеансаВыгрузки>
</КонтрольныйЛистСеанса>
<Документ Тип="Осн_док" Номер="00/010017/810/0">
  <Тип>Осн_док</Тип>
  <Дата>25-02-2005</Дата>
  <Номер>00/010017/810/0</Номер>
  <Форма>Осн_док</Форма>
  <ШтатнаяЕдиница>12_10000000534</ШтатнаяЕдиница>
  <Субъект>12_10000096580</Субъект>
  <Операция>DEPF</Операция>
  <Валюта>810</Валюта>
  <СуммаДокумента>0.0</СуммаДокумента>
  <Дата_откр>04-02-2002</Дата_откр>
  <Дата_закр>04-02-2002</Дата_закр>
  <Балсчет>42301</Балсчет>
  <Необ_сумма>493.85</Необ_сумма>
  <Ссуд_счет>42301810615000010017</Ссуд_счет>
  <Код>12_DLG_10000000032_25-02-2005</Код>
  <Документы>
  </Документы>
  <Документы>
  </Документы>
</Документ>
<ЗавершитьСеанс/>
</Сеанс>

Рис.1. Пример основного документа позиции по сделке в XML-формате.

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

<?xml version="1.0" encoding="windows-1251" ?>
<?Contour version="2.0" ?>

<Приложение xml_ver="1.0" СерверБД="tokmakov" БазаДанных="TCB">
  <БанкиДанных Количество="1" xml_ver="1.0">
    <БанкДанных xml_ver="1.0">
      <Категория>DC</Категория>
      <Название>Документы</Название>
      <ТипыОбъектов Количество="1" xml_ver="1.0">
        <Категория>DC</Категория>
        <ТипОбъектов xml_ver="1.0">
          <Категория>DC</Категория>
          <Статус>N</Статус>
          <Код>Док_граф</Код>
          <ИмяТаблицы>dc_docgraf</ИмяТаблицы>
          <Название>Документ графика</Название>
          <Описание>Документ графика</Описание>
          <АтрибутыТипа Количество="3" xml_ver="1.0">
            <АтрибутТипа xml_ver="1.0">
              <Статус>N</Статус>
              <Код>Проц_куп</Код>
              <Название>Процент по купону</Название>
              <КодДомена>udf_da_perc</КодДомена>
              <ИмяПоля>perc_warr</ИмяПоля>
              <КонтрольЦелостности>N</КонтрольЦелостности>
              <Описание>Процент по купону</Описание>
            </АтрибутТипа>
            <АтрибутТипа xml_ver="1.0">
              <Статус>N</Статус>
              <Код>Дата_граф</Код>
              <Название>Дата записи графика</Название>
              <КодДомена>udf_da_date</КодДомена>
              <ИмяПоля>linedate</ИмяПоля>
              <КонтрольЦелостности>N</КонтрольЦелостности>
              <Описание>Дата записи графика</Описание>
            </АтрибутТипа>
            <АтрибутТипа xml_ver="1.0">
              <Статус>N</Статус>
              <Код>Привед_сум</Код>
              <Название>Приведенная сумма</Название>
              <КодДомена>udf_da_money</КодДомена>
              <ИмяПоля>reduced_sum</ИмяПоля>
              <КонтрольЦелостности>N</КонтрольЦелостности>
              <Описание>Приведенная сумма</Описание>
            </АтрибутТипа>
          </АтрибутыТипа>
        </ТипОбъектов>
      </ТипыОбъектов>
    </БанкДанных>
  </БанкиДанных>
</Приложение>

Рис.2 Пример XML-формата документа графика платежей.

После разработки форматов обмена данными была выполнена настройка структуры хранения данных по сделкам в Хранилище "Контур Корпорация" и разработаны процедуры выгрузки данных по отдельным видам сделок из бек-офисных модулей ИБС в формат XML. Для сверки загруженных в Хранилище позиций по отдельным видам сделок с данными бухгалтерского учета дополнительно разработали специальные процедуры.

Состав собираемых сделок

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

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

Всего на основе стандартизованного шаблона в Хранилище данных банка в ежедневном режиме поступает информация о 26 видах сделок банка c различными финансовыми инструментами. Из них 4 вида сделок не ведутся в основной АБС банка, а собираются из специализированных модулей сторонних поставщиков и приложений собственной разработки ИТ-службы банка.

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

Практические результаты

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

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

  1. Анализ кредитного портфеля в разрезе договоров, банковских продуктов и др., формирование ежедневного отчета о кредитных позициях и расчет кредитного риска специалистами Отдела кредитования корпоративных клиентов. Планируется, что в ближайшее время на основе той же технологии будет налажен расчет валютного риска.
  2. Генерация потоков платежей по сделкам и получение отчета о ликвидности банковской группы специалистами Отдела планирования и управленческой отчетности.
  3. Учет и анализ тарифной политики банка специалистами Управлений кредитования физических и юридических лиц в филиалах банка.
  4. Сбор и консолидация первичных данных и выпуск комплекта отчетов, которые используются при выполнении корректировок и подготовке расшифровок к отчетности по МСФО для Отдела отчетности по международным стандартам банка. Данные в этих отчетах, прежде всего, дают составителям отчетности по МСФО детальную информацию о сделках филиалов. Эти отчеты используются непосредственно при подготовке отчетности по МСФО, а также предоставляются аудиторам, которые заверяют отчетность.
  5. Расчет доходности по клиентам и банковским продуктам на основании данных первичного бухгалтерского учета и сделок. Это решение реализовано по заказу Управления банковских продуктов. OLAP-отчеты по доходности клиентов и банковских продуктов подготавливаются на основе аналитических документов управленческого учета, в которых хранятся суммы платежей, коды клиентов и банковских продуктов. Аналитические документы формируются на основе проводок по лицевым счетам доходов и расходов. Лицевые счета "раскрашены" кодами статей управленческого учета и банковских продуктов. Проводки загружаются в Хранилище размеченные кодами сделок, по которым совершен платеж. При создании аналитических документов управленческого учета специальный механизм Хранилища, обращается к сделке, код которой указан в проводке, и получает из нее код клиента и банковского продукта. Таким образом, из управленческого учета может быть получена полная информация по сделкам в разрезе клиентов и банковских продуктов. Применяя механизмы OLAP для анализа отчетов по доходности клиентов, можно определить клиентов, приносящих наибольший доход, выявить продукты, которые пользуются наибольшим спросом и т.д.
  6. Подготовка реестра клиентов-физических лиц. Отчет готовится для передачи в ЦБ РФ банками-участниками системы страхования вкладов. Для выверки реестра в процессе загрузки в Хранилище выполняется сверка сделок с данными первичного бухгалтерского учета.

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

Автор: Ю. Амириди

Источник: Банки и технологии, 2005, № 1