Адаптивное хранилище данных как технологический базис экосистемы банка

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Адаптивное хранилище данных как технологический базис экосистемы банка

Е.В. Васильева, К.С. Солянов, Т.Д. Коневцева

АННОТАЦИЯ

В современных условиях цифровой трансформации банковского бизнеса появляются новые ориентиры - омниканальность и экосистемность. Для улучшения клиентского опыта взаимодействия с банковскими сервисами все больше банков переходят на омниканальную модель, в которой клиент получает возможность совершать операции в едином интерфейсе в любом из способов коммуникации, не ощущая разницы в процессах между офлайн-операциями в офисах и удаленных онлайн-каналах. Это требует изменений в ИТ-ландшафте банка, центром которого является банковское хранилище данных. Цель данного исследования - показать возможность развития методики проектирования банковского хранилища данных для его конфигурирования под новые бизнес-проекты и задачи. Авторы использовали следующие методы исследования: анализ, логическое моделирование выявленных взаимосвязей. Разработан конструктор адаптивного банковского хранилища данных в средах SAP Power Designer, Star UML, PL/SQL Developer. В результате рассмотрен подход к формированию адаптивной модели банковского хранилища данных, в основе которого реализован принцип разбиения данных на компоненты. Такое деление позволяет устанавливать контуры хранилища под конкретные бизнес-задачи, комбинировать элементы и расширять структуру банковского хранилища данных в условиях его интеграции с различными внешними программными объектами. Выделена взаимосвязь компонентов банковского хранилища данных и решаемых бизнес-задач, список которых может быть расширен в условиях реализации различных проектов банка. Подробно описан базовый набор компонентов адаптивной модели банковского хранилища данных, который может использоваться в качестве основы проектирования банковского хранилища данных под конкретную бизнес-задачу. Приведены модель данных и атрибутный состав компонента «Главная книга», модель данных компонента «Пластиковые карты», описаны компоненты «Сделки», «Заявки», «Контрагенты» и др., указаны связи между компонентами. Показаны особенности проектирования банковского хранилища данных нового типа. В качестве отдельной задачи рассмотрены технологические особенности создания единой фронтальной системы омниканального банка. Сделан вывод, что разработанный базовый набор компонентов и бизнес-объектов адаптивного банковского хранилища данных позволит обеспечить целостность данных и сократить временные затраты проектирования.

Ключевые слова: клиентский путь; банк; омниканальность; экосистема; хранилище данных; проектирование; методика; информационные системы; цифровые сервисы

Adaptive Data Warehouse as the Technological Basis of the Banking Ecosystem. E. V. Vasilieva, K. S. Solyanov, T. D. Konevtseva

ABSTRACT

New guidelines of omnichannel and ecosystem are emerging driven by modern digital transformation of the banking business. To improve customer experience of interaction with banking services more banks are switching to the omnichannel model. In this model, the customer is able to perform operations in a unified interface using any communication methods, and sees no difference in the processes between off-line and on-line operations. This requires changes in a bank's IT architecture, whose center is a bank data warehouse. The aim of this study is to show the possibility of developing a method for designing a banking data warehouse so that it can be easily adaptable for new business projects and tasks. The authors used the following research methods: analysis, logical modeling of the identified relationships. They developed an adaptive banking data warehouse designer in the environments of SAP PowerDesigner, StarUML, PL/SQL Developer. The article tackles the approach towards development of an adaptive model of a banking data warehouse, based on the principle of splitting data into components. It makes it possible to set the warehouse contours for specific business tasks, combine elements, and expand the structure of the banking data warehouse in the context of its integration with various external software objects. The article highlights the interaction between the components of the banking data warehouse and business tasks, the list of which can be expanded in the context of various bank projects. The article provides a detailed description of the basic set of components of the adaptive banking data warehouse model. This set may serve as the foundation for designing a banking data warehouse for a specific business task. The article provides the data model and attribute composition of the General Ledger component, the data model of the Plastic Cards, Transactions, Applications, Contractors, etc. components, as well as indicates the relationships between the components. The study presents design features of a new type of the banking data warehouse. The authors concentrate on the technological features of creating a unified front-end omnichannel banking system as a separate task. They conclude that the developed basic set of components and business objects of adaptive banking data warehouse will ensure data integrity and reduce design time.

Keywords: client path; bank; omnichannel; ecosystem; data warehouse; design; methodology; information systems; digital services

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

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

Тренд на формирование экосистемы в бизнесе впервые возник более 20 лет назад и успешно реализовался в стратегиях ИТ- и сервисных компаний.

Сильный банк в состоянии сопровождать клиента в течение всей жизни, «провести человека через весь его цифровой день» Going digital: The banking transformation road map. A. T. Kearney &Efma. 2014. Экосистема экосистем. Стратегия Mail.ru Group. URL: https://corp.mail.ru/ru/company/strategy_ceo/?fbclid= IwAR1baqZoMkJKGhGH8_bqlU6-9kwhszoxdRTffAqiFZvu3B- WCOAdsu_LR3A (дата обращения: 28.02.2020). так, что ему не нужно будет переходить от предложения банка к продукту другой компании. Обладая обширной информацией о своих клиентах, банк может монетизировать ее, предоставив множество разнообразных продуктов.

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

Новая сетевая экономика построена как единая экосистема, в центре которой -- клиент, вокруг которого формируются и четко взаимодействуют три орбиты мышления, определяющие стратегию компании: позиция на рынке, изменение бизнес- процессов, реакция на инновации. Уже сегодня банки создают экосистемы, выходя за рамки ИТ- и fintech-стартапов, активно реализуя собственные проекты в здравоохранении, образовании, ритейле и отчасти транспорте. В некоторой степени для банков толчок к эволюции в экосистему дала принятая в Европе платежная директива PSD2, направленная на расширение конкуренции на рынке платежных услуг. Она повлияла на то, что банки начали предоставлять открытый доступ к API(от англ. Application Programming Interface -- программный интерфейс приложения, с помощью которых разработчики могут создавать свои программы, приложения, скрипты для работы с серви- сом Что такое API Директа. URL: https://yandex.ru/dev/direct/ doc/start/intro-docpage/ (дата обращения 20.02.2020).). Обслуживание банком клиентов в открытом формате (openbanking) не только внесло коррективы в банковскую технологическую инфраструктуру, но и усилило конкуренцию. Чтобы продолжать соответствовать требованиям рынка и ожиданиям клиента в качестве новых шагов, банки выбирают построение общей экосистемы (lifestyle banking), в которой одно мобильное банковское приложение может покрыть почти 100% потенциальных нужд клиента в любой сфере жизни -- от покупки продуктов до приобретения жилья, от выбора и оплаты обучающих курсов до заказа еды.

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

В российской банковской отрасли парадигму экосистем внедряют АО «Альфа-Банк», АО «Тинькофф Банк», Банк ВТБ (ПАО) и другие банки. ПАО Сбербанк принял к реализации стратегию, согласно которой к 2020 г. он трансформируется в универсальную технологическую компанию. В декабре 2018 г. была создана дирекция по развитию экосистемы SberX Сбербанксменил руководителя своейэкосистемьЬегХ. URL:. Экосистема ПАО Сбербанк включает уже более 20 разных компаний. Сегодня ПАО Сбербанк продает кофе в своих отделениях, совместно с Mail.Ruобеспечивает доставку еды, с Rabota. ru -- подбирает вакансии, с DocDoc-- открывает доступ к телемедицине, с Яндекс.Маркет -- ведет интернет-торговлю (Яндекс.Маркет, маркетплейсы Беру! и Bringly), ДомКлик -- оказывает услуги по продаже квартир. В 2020 г. в московском отделении ПАО Сбербанк у метро «Новослободская» открыты зоны МакКафе, а рядом на стене закреплен планшет, с помощью которого клиент может сделать заказ из стандартного меню McDonald'sи заказать доставку еды в отделение. Сегодня передовой банк встроился в цепочку добавленной стоимости во многих сегментах. Взамен партнеры получили доступ к данным о клиентах. Внедрение новых технологий поддерживает ИТ-функционал экосистемы, в том числе через сервисы идентификации, быстрого обмена данными и др. Экосистема имеет открытые интерфейсы или обеспечивает совместимость: удобство, безопасность. Единые программные интерфейсы облегчают подключение к платформе.

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

Для перехода на омни-модель банк наращивает портфель программных сервисов. Так, ПАО Сбербанк приобрел и ввел в свой бренд заявившие о себе на рынке сервисы, а также запустил облачную платформу SberCloud. АО «Тинькофф Банк» создает собственные сервисы и занимается интеграцией сторонних, предлагая клиентам более 120 партнерских программhttps://www.vedomosti.ru/finance/news/2019/07/03/805704- sberbank-smenil-rukovoditelya-ekosistemi(дата обращения: 28.02.2020).. Это также накладывает определенные требования к изменению технологической платформы.

АРХИТЕКТУРНЫЕ ПРИНЦИПЫ СОЗДАНИЯ ЕДИНОЙ ФРОНТАЛЬНОЙ СИСТЕМЫ ОМНИКАНАЛЬНОГО БАНКА

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

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

Рис. 1. Основные задачи формирования стратегии трансформации клиентского опыта на основе омниканальности

Технологическую основу банкинга составляет многокомпонентная платформа BaaS (Banking-as-a-Service, Банкинг как услуга) Going digital: The banking transformation road map. A. T. Kearney &Efma. 2014.. В этом случае сложные банковские приложения существуют в виде веб-сервисов. С точки зрения ИТ-архитектуры это означает переход от «монолитных» независимых систем, каждая из которых обслуживает ограниченное число каналов, реализуя собственную бизнес-логику и набор сервисов, к единой архитектуре фронтальных приложений. Она отражает сервисную модель, обеспечивает оптимальный клиентский интерфейс с учетом особенностей канала, опирается на единый бизнес-узел всей сети.

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

* вызовы канало-зависимых подпроцессов или сервисов (если это реализуется, например, для подпроцессов идентификации, оформления кредита, открытия вклада или осуществления перевода).

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

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

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

В центре проекта омниканальности должно быть внедрение подходов дизайн-мышления [1-5] и управления продуктом в принципах Lean Start Up [6-8]. При реализации фронтальных решений необходимо итеративно подходить к разработке макетов пользовательских интерфейсов, применять инструменты и методы дизайн-мышления, usabilityтестирование. Помимо этого, важно проводить анализ клиентского поведения и оптимизировать бизнес-функциональность, определять причины обращения клиента, прерывания им операции. Главное, понимать, что действия клиента -- его голос. программный банковский омниканальность экосистема

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

При реализации омниканального подхода одновременно решается задача удобства и отлаженности цифровых каналов, а также сохраняется возможность общения с клиентом в рамках личных контактов [9-13].

РОЛЬ ХРАНИЛИЩА ДАННЫХ В РАЗВИТИИ БАНКОВСКОГО БИЗНЕСА В ЭПОХУ ЦИФРОВОЙ ТРАНСФОРМАЦИИ

Классическое определение хранилища данных Б. Инмона [14] как «предметно-ориентированного набора данных» сегодня может быть расширено с учетом ориентиров на бизнес-специфику. К основному назначению хранилища данных, связанному с подготовкой отчетов и проведением бизнес-анализа в организации, добавляются расширенные функции обеспечения клиентоориентированности и персонализация предложений, покрытие потребностей клиента на 360о, взаимодействия с партнерами в большом пуле задач, в том числе за рамками привычных для банка сфер деятельности, гибкого преобразования имеющихся и внедрение новых продуктовых направлений.

Возможно, одним из сдерживающих факторов развития банковской сферы является недооценка возможностей технологии проектирования хранилища данных. Хранилище данных должно быть интегрированной (единой) коллекцией данных с централизованным управлением [15], отвечать потребностям всех подразделений компании по принципу “source once, distribute many times” [16] и решать задачу сбора и обработки данных из разнородных источников, поддерживая весь информационно-технологический ландшафт банка.

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

Концепция адаптивного банковского хранилища данных

В основе бизнес-ориентированного подхода лежит методология GRAnD (от англ. goal-oriented approach to requirement analysis in data warehouses -- ориентированный на достижение целей бизнеса подход к анализу требований к хранилищу данных), позволяющая проектировать хранилище данных с учетом потребностей и особенностей организации [17, 18]. Потребности роста информационной поддержки требуют усилий по уточнению модели и, при необходимости, доработке банковского хранилища данных (БХД) в условиях его адаптации под конкретные задачи. Этот процесс может быть упрощен за счет проектирования универсальной модели хранилища данных, которая может быть адаптирована под новые бизнес-цели, тем самым став основой для проектирования адаптивного банковского хранилища данных. Разработка на основе ранее созданных компонент, которые модифицируются под новые требования,--частый прием в создании программных продуктов [19, с. 40]. Для этого первоначально составляется базовый состав задач, по которым прорабатываются и формализуются новые бизнес-требования, технические требования к хранилищу данных, а затем они реализуются в соответствии с выбранной референтной моделью.

Рис. 2. Функции хранилища данных в задачах управления бизнес-процессами банка

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

Модель адаптивного банковского хранилища данных описывает ключевые элементы банковской предметной области и содержит базовый набор компонентов и бизнес-объектов. Покомпонентная разработка систем с адаптацией под новые требования применяется в создании программного обеспечения с конца 1990-х гг. Возможностям повторного использования компонентов посвящены работы [19-22]. Согласно И. Соммервилл, обобщенные модели не столько точно описывают объект или процесс, сколько представляют «полезные абстракции, помогающие „приложить” различные подходы и технологии к процессу разработки» [19].

В предложенной классификации B. Meyer[20] компоненты адаптивного банковского хранилища данных относятся к уровню системной абстракции и могут быть применены в различных модификациях.

В работе [21] получила свое развитие идея обобщенных паттернов С. Александера [22]. Так, Э. Гамма, Р. Хелм, Р. Джонсон и Дж. Влассидес называют проектный паттерн (design patterns) шаблоном проектного решения, который может быть изменен под различные ситуации проблемной области. И. Сом-мервилл отмечает, что такой многокомпонентный подход позволяет снизить затраты на разработку, ускорить сам процесс проектирования [19].

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

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

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

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

Рис. 3. Архитектура адаптивной модели банковского хранилища данных

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

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

Рис. 4. Базовый набор компонентов и бизнес-объектов

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

• для связи двух бизнес-объектов (в том числе разных компонентов), например «Связь сделки и счета»;

• для связей экземпляров одной сущности, в том числе для отражения иерархии объектов, например «Связь сделок».

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

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

Модель данных компонента «Главная книга» модели адаптивного банковского хранилища данных представлена на рис. 5.

В главной книге ведется информация обо всех банковских счетах, их основных реквизитах. Кроме того, здесь хранится фактовая информация, а именно:

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

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

Рис. 5. Компонент «Главная книга» (фрагмент)

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

• остаток по счету -- это сумма всех оборотов по счету на какой-либо момент времени (обычно на конец банковского дня).

Некоторые счета могут быть связаны друг с другом, например связь счета актива и счета резерва этого актива. Счета могут пребывать в различных статусах: открыт, закрыт, арестован, заблокирован и т.д. Базовые атрибуты таблиц компонента «Главная книга» представлены в таблице.

В компоненте «Сделки» содержатся сущности, схожие с составом компонента «Главная книга», но относящиеся к сделкам (договорам). Это, например, сущности «Связь сделок», «Статус сделки», «Остаток по сделке». Также в компоненте «Сделки» находятся специфические сущности. Такой сущностью является «Срочность сделки», которая содержит информацию о сроке действия договора и плановой дате закрытия. Срочность сделки может изменяться, например, в результате пролонгации (в случае депозитов). Для сделок характерно наличие различных процентных ставок (например, для кредитов): основная процентная по основному долгу; по просроченному основному долгу; на неуплаченную сумму комиссии и т.д.

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

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

Модель данных компонента «Пластиковые карты» (фрагмент представлен для кредитных карт) изображена на рис. 6. Сделки с пластиковыми картами также имеют свои особенности. Во- первых, с одним договором может быть связано сразу несколько пластиковых карт: одна основная и множество дополнительных. При этом весь учет денежных средств ведется в рамках договора, а также имеется кредитный лимит, т.е. какой объем денежных средств клиент может получить в долг. Для самой же пластиковой карты так же, как для сделки характерен лимит, который устанавливает сам клиент в рамках лимита по сделке, и статус. Также для пластиковой карты характерны транзакции -- аналог операций по сделке, но со спецификой учета в процессинговой системе.

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

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

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

Таблица 1. Атрибутный состав сущностей компонента «Главная книга» (фрагмент)