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

Адаптивное хранилище данных как технологический базис экосистемы банка Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
291
36
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
КЛИЕНТСКИЙ ПУТЬ / БАНК / ОМНИКАНАЛЬНОСТЬ / ЭКОСИСТЕМА / ХРАНИЛИЩЕ ДАННЫХ / ПРОЕКТИРОВАНИЕ / МЕТОДИКА / ИНФОРМАЦИОННЫЕ СИСТЕМЫ / ЦИФРОВЫЕ СЕРВИСЫ / CLIENT PATH / BANK / OMNICHANNEL / ECOSYSTEM / DATA WAREHOUSE / DESIGN / METHODOLOGY / INFORMATION SYSTEMS / DIGITAL SERVICES

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Васильева Елена Викторовна, Солянов Кирилл Сергеевич, Коневцева Татьяна Дмитриевна

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

i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

ADAPTIVE DATA WAREHOUSE AS THE TECHNOLOGICAL BASIS OF THE BANKING ECOSYSTEM

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.

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

ОРИГИНАЛЬНАЯ СТАТЬЯ

(СО ]

DOI: 10.26794/2587-5671-2020-24-3-132-146 УДК 004,007(045) JEL M15, О32

Адаптивное хранилище данных

как технологический базис экосистемы банка

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

a Финансовый университет, Москва, Россия; b ООО «Глоубайт аналитические решения», Москва, Россия;

с ПАО «ВТБ», Москва, Россия a https://orcid.org/0000-0002-0054-832X; b https://orcid.org/0000-0003-4563-2477;

с https://orcid.org/0000-0001-6262-7288 н Автор для корреспонденции

АННОТАЦИЯ

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

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

Для цитирования: Васильева Е. В., Солянов К. С., Коневцева Т. Д. Адаптивное хранилище данных как технологический базис экосистемы банка. Финансы: теория и практика. 2020;24(3):132-146. DOI: 10.26794/2587-5671-2020-24-3-132-146

ORIGINAL PAPER

Adaptive Data Warehouse as the Technological Basis of the Banking Ecosystem

E. V. Vasilievaa K. S. Solyanovb, T. D. Konevtsevac

a Financial University under the Government of the Russian Federation, Moscow, Russia; b Glowbyte Analytical Solutions, Moscow, Russia; c PJSC VTB BANK, Moscow, Russia a https://orcid.org/0000-0002-0054-832X; b https://orcid.org/0000-0003-4563-2477;

c https://orcid.org/0000-0001-6262-7288 H Corresponding author

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

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

BY 4.0

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/SOL 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

For citation: Vasilieva E.V., Solyanov K. S., Konevtseva T. D. Adaptive data warehouse as the technological basis of the banking ecosystem. Finance: Theory and Practice. 2019;24(3):132-146. (In Russ.). DOI: 10.26794/2587-5671-2019-24-3-132-146

ВВЕДЕНИЕ

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

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

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

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

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

БАНКОВСКИЕ ЭКОСИСТЕМНЫЕ ПЛАТФОРМЫ

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

1 Going digital: The banking transformation road map. A. T. Kearney & Efma. 2014.

2 Экосистема экосистем. Стратегия 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 — программный интерфейс приложения, с помощью которых разработчики могут создавать свои программы, приложения, скрипты для работы с серви-сом3). Обслуживание банком клиентов в открытом формате (open banking) не только внесло коррективы в банковскую технологическую инфраструктуру, но и усилило конкуренцию. Чтобы продолжать соответствовать требованиям рынка и ожиданиям клиента в качестве новых шагов, банки выбирают построение общей экосистемы (lifestyle banking), в которой одно мобильное банковское приложение может покрыть почти 100% потенциальных нужд клиента в любой сфере жизни — от покупки продуктов до приобретения жилья, от выбора и оплаты обучающих курсов до заказа еды.

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

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

3 Что такое API Директа. URL: https://yandex.ru/dev/direct/ doc/start/intro-docpage/ (дата обращения 20.02.2020).

4 Сбербанксменил руководителя своейэкосистемыSberX. URL:

https://www.vedomosti.ru/finance/news/2019/07/03/805704-sberbank-smenil-rukovoditelya-ekosistemi (дата обращения: 28.02.2020).

зоны МакКафе, а рядом на стене закреплен планшет, с помощью которого клиент может сделать заказ из стандартного меню McDonald's и заказать доставку еды в отделение. Сегодня передовой банк встроился в цепочку добавленной стоимости во многих сегментах. Взамен партнеры получили доступ к данным о клиентах. Внедрение новых технологий поддерживает ИТ-функционал экосистемы, в том числе через сервисы идентификации, быстрого обмена данными и др. Экосистема имеет открытые интерфейсы или обеспечивает совместимость: удобство, безопасность. Единые программные интерфейсы облегчают подключение к платформе.

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

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

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

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

5 Going digital: The banking transformation road map. A. T. Kearney & Efma. 2014.

Разработка стратегии развития офлайн-каналов обслуживания - • Мобильные рабочие места сотрудников • Цифровые устройства в офисе

С N Пересмотр организационной структуры ч • Передача управления бизнес-функциональностью от владельца канала владельцу продукта

• Персонализация предложений, внедрение CRM-системы • Оценка эффективности процессов, внедрение BPM-системы • Тесная интеграция с back-office • Оптимизация веб-сайта и приложений

( > Изменения ИТ-ландшафта V J

Г Л Вывод функционала в инновационные каналы обслуживания V - • Геймификация • Чат-боты J

С N Цифровой бренд V • Конференции и профессиональные сообщества • Активная позиция в социальных сетях • Сбор и анализ лучших практик

С N Корпоративная культура - • Дизайн-мышление для персонала • Методология Agile в проектной работе

С N Цифровые социальные инновации • Персональные предложения (Customer Sensing) • Социальные программы • Социальная устройчивость в продуктах ,

Рис. 1 /Fig. 1. Основные задачи формирования стратегии трансформации клиентского опыта на основе омниканальности / Key strategic objectives to transform customer experience based on omnichannel

Источник/Source: составлено авторами / complied by the authors.

действие с клиентом создается на основе объединения фронт- и бэк-офисов, всех процессов банка, модернизации всей модели обслуживания.

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

Технологическую основу банкинга составляет многокомпонентная платформа BaaS (ВапЫ^-

as-a-Service, Банкинг как услуга)6. В этом случае сложные банковские приложения существуют в виде веб-сервисов. С точки зрения ИТ-архитектуры это означает переход от «монолитных» независимых систем, каждая из которых обслуживает ограниченное число каналов, реализуя собственную бизнес-логику и набор сервисов, к единой архитектуре фронтальных приложений. Она отражает сервисную модель, обеспечивает оптимальный клиентский интерфейс с учетом особенностей канала, опирается на единый бизнес-узел всей сети.

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

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

6 Going digital: The banking transformation road map. A. T. Kearney & Efma. 2014.

для подпроцессов идентификации, оформления кредита, открытия вклада или осуществления перевода).

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

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

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

В центре проекта омниканальности должно быть внедрение подходов дизайн-мышления [1-5] и управления продуктом в принципах Lean StartUp [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 —

Управление Планирование и контроль ключевых показателей эффективности, КР1 стратегическим

развитием и -

операционной Функционально-стоимостной анализ и оптимизация бизнес-процессов деятельностью

Управление Оценка прибыльности и рентабельности банковских продуктов, клиентов

корпоративным и и каналов сбыта

розничным -

блоком Анализ доходности и эффективности клиентов

Финансовое Бюджетирование и управленческую отчетность по банку, филиалам

управление и подразделениям

Обязательная отчетность, подготовку налоговых деклараций и отчетность по МСФО

Маркетинг Оценка эффективности продуктовой политики, затрат на маркетинг

Формирование гибкого ценообразования

Управление Персонализация и таргетирование предложения

продуктом

Омниканальные сервисы

Рис. 2/Fig. 2. Функции хранилища данных в задачах управления бизнес-процессами банка / Data warehouse functions in business process management tasks of a bank

Источник/Source: составлено авторами / complied by the authors.

ориентированный на достижение целей бизнеса подход к анализу требований к хранилищу данных), позволяющая проектировать хранилище данных с учетом потребностей и особенностей организации [17, 18]. Потребности роста информационной поддержки требуют усилий по уточнению модели и, при необходимости, доработке банковского хранилища данных (БХД) в условиях его адаптации под конкретные задачи. Этот процесс может быть упрощен за счет проектирования универсальной модели хранилища данных, которая может быть адаптирована под новые бизнес-цели, тем самым став основой для проектирования адаптивного банковского хранилища данных. Разработка на основе ранее созданных компонент, которые модифицируются под новые требования,—частый прием в создании программных продуктов [19, с. 40]. Для этого первоначально составляется базовый состав задач, по которым прорабатываются и формализуются новые бизнес-требования, технические требования к хранилищу данных, а затем они реализуются в соответствии с выбранной референтной моделью.

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

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

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

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

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

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

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

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

\

Г-\

Сущности

логической модели данных

V _)

с л

Бизнес-объекты

ч У

с Компоненты N

V У

Рис. 3 / Fig. 3. Архитектура адаптивной модели банковского хранилища данных / Architecture of the adaptive model of a banking data warehouse

Источник / Source: составлено авторами / complied by the authors.

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

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

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

Сделки

Остатки по сделкам Сделки fOPiOObIC площадки

Объекты сделок на фннанеогдам цинке Обссгечения

Коти линии ОЙЪЯНТОЛ SJMjjMjl^jjjMjMWjj РЫЯКе

Зм вш по еде лкаи

Связисделок со счетами

Докчменгипосделшм

Графики пддтежей

Опедащмпосдаддам

Тарифы

Лим и гы п о с де л кам

Намси&нуд с j'.f/i он

Смдм сделок с ипндацнтдыи

С ПЯДИ I14DH и дмн^т

Рнгнпиир- гдгл«к

Процентный ЯШИ

главная ннига

Остатки по счетам

Счета

п л j тсн" ыс дпцу hf нтм

ck5t4>ptm д d сч вта м пронрлки

я

КРШИДИДЫ

надшит

lj ис*0| щд рид цщц кг >14 j?n i пн г 0г1

Анкеты контрагентов Контактные душные континентов

Контдктын; контрагентами ОЙнздте л ьства контра ге нтон

Финансовые показатели Денежные потоки контрагентов

Дея тельное ть контрагентов Документы контрагент«!

Банковские карты

Транзакции

Услуги пр плпотнкоиърм карт am

Скнть к Bin и сделок ЛИМИТЫ по картва1

Связь МЕЦ1Т и контрагенте]в Пластиковые нарты

Устройства обелузкивання пластнковык карт

Связь транзакции и проводки

Общие КЛПССИФИУДТСФЫ

Рис. 4 / Fig. 4. Базовый набор компонентов и бизнес-объектов / Basic set of components and business objects

Источник/Source: разработано авторами / developed by the authors.

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

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

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

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

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

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

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

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

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

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

• платежный документ — это документ, который породил проводку; в нем содержится де-

Платежный документ

верификатор платежного документа Номер платежного документа Описание платежного докумгчтп

Статус счета

vдсн miii op счета Статус

Дата начал а действия статуса Дата окончании /;енг.тн™ ИтДтуСв

Лронсдка гс «чету

l^sh г ифика i op грОвадки

Счет по дебету Счет по кредиту Дата прпнп^кь1 {^мма прСоОдки Платежный документ

Ж 5

1

О

снизь счйтов

счет

Идентификатор счета

Номер счета

Дата отирьпия

Дата закрытий

Валюта

Доч^ний Счет Родетельсиий счет Тип связи счетов Дата начата действии свизи Дата Оийнчлшн ли i и luhjn

Оборот пс счету

ь^д&нтнфжагор снега Дата оборота Сумма оборота по дебету Сумма оборота пи кредиту

Z

1

Остаток го счету

V ден i иф ишп L41 с 4ti а Дата начала действия остатка Дата окончаш\и действия остатка Сумма Ойт^ткй ПО счету

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

Источник/Source: разработано авторами / developed by the authors.

тальная информация о назначении проводки, обороты;

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

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

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

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

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

(в случае депозитов). Для сделок характерно наличие различных процентных ставок (например, для кредитов): основная процентная по основному долгу; по просроченному основному долгу; на неуплаченную сумму комиссии и т.д.

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

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

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

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

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

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

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

Таблица / Table Атрибутный состав сущностей компонента «Главная книга» (фрагмент) / Attribute composition of the entities of the General Ledger component (fragment)

Сущность / Entity Атрибут / Attribute

Счет Идентификатор счета

Счет Номер счета

Счет Дата открытия

Счет Дата закрытия

Счет Валюта

Связь счетов Дочерний счет

Связь счетов Родительский счет

Связь счетов Тип связи счета

Связь счетов Дата начала действия связи

Связь счетов Дата окончания действия связи

Оборот по счету Идентификатор счета

Оборот по счету Дата оборота

Оборот по счету Сумма оборота по дебету

Оборот по счету Сумма оборота по кредиту

Статус счета Идентификатор счета

Статус счета Статус

Статус счета Дата начала действия статуса

Статус счета Дата окончания действия статуса

Проводка по счету Идентификатор проводки

Проводка по счету Счет по дебету

Проводка по счету Счет по кредиту

Проводка по счету Дата проводки

Проводка по счету Сумма проводки

Проводка по счету Платежный документ

Платежный документ Идентификатор платежного документа

Платежный документ Номер платежного документа

Платежный документ Описание платежного документа

Источник/Source: разработано авторами / developed by the authors.

Рис. 6 / Fig. 6. Компонент «Пластиковые карты» (фрагмент) / Plastic cards component (subpicture)

Источник/Source: разработано авторами / developed by the authors.

Несмотря на относительную унитарность компонентов модели, все компоненты связаны между собой:

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

• «Главная книга» связана с компонентом «Пластиковые карты» через сущность-мост «Связь транзакции и проводки по счету»;

• сущность «Кредитная сделка» компонента «Кредиты» является дочерней по отношению к сущности «Сделка» компонента «Сделки (база)», т.е. компоненты «Кредиты» и «Сделки (база)» имеют связь «один к одному» по полю «Идентификатор сделки»;

• сущность «Сделка по пластиковым картам» компонента «Пластиковые карты» является дочерней по отношению к сущности «Сделка» компонента «Сделки (база)», т. е. компоненты «Пластиковые карты» и «Сделки (база)» имеют связь «один к одному» по полю «Идентификатор сделки»;

• сущность «Сделка на фин. рынке» компонента «Сделки на финансовом рынке» является дочерней по отношению к сущности «Сделка» ком-

понента «Сделки (база)», т.е. компоненты «Сделки на финансовом рынке» и «Сделки (база)» имеют связь «один к одному» по полю «Идентификатор сделки»;

• сущность «Кредитная сделка» компонента «Кредиты» связана с сущностью «Заявка» компонента «Заявки» по атрибуту «Идентификатор сделки»;

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

• сущность «Анкета» компонента «Заявки» связана с сущностью «Контрагент» компонента «Контрагенты» по атрибуту «Идентификатор контрагента»;

• сущность «Пластиковая карта» компонента «Пластиковые карты» связана с сущностью «Контрагент» компонента «Контрагента» по атрибуту «Контрагент владелец карты»;

• сущность «Ценная бумага» компонента «Сделки на финансовом рынке» связана с сущностью «Юридическое лицо» компонента «Контрагенты» по атрибуту «Контрагент эмитент».

Таким образом, взаимосвязь компонентов адаптивной модели банковского хранилища данных можно представить в виде схемы (рис. 7).

Кредиты

/

Контрагенты

Сделки на финансовом рынке

Рис. 7/ Fig. 7, Взаимосвязь компонентов референтной модели банковского хранилища данных / Interaction between the components of the reference model of a banking data warehouse

Источник/Source: разработано авторами / developed by the authors.

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

Методика проектирования адаптивного банковского хранилища данных: ключевые шаги

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

1. Вербальное высокоуровневое описание автоматизируемых бизнес-процессов.

2. Классификация и группировка бизнес-процессов с целью выявления направлений деятельности.

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

4. Определение необходимых компонентов хранилища из базового набора адаптивного банковского хранилища данных.

5. Выбор требуемых бизнес-объектов из базового набора адаптивного банковского хранилища данных и их обогащение под особенности конкретной организации в соответствии с его архитектурой.

6. Детализация бизнес-объектов до сущностей логической модели, установление связей между ними, разработка ER-модели.

7. Наполнение ручных справочных бизнес-объектов.

8. Разработка функциональной архитектуры прикладных систем.

ВЫВОДЫ

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

ствия преимущественно через цифровые каналы. Высокая конкуренция с финтех-компаниями заставляет банки становиться полностью цифровым. А полностью цифровая организация построена на цифровых технологиях.

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

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

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

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

СПИСОК ИСТОЧНИКОВ

1. Леврик М., Линк П., Лейфер Л. Дизайн-мышление. От инсайта к новым продуктам и рынкам. Пер. с англ. СПб.: Питер; 2020. 320 с.

2. Going digital: The banking transformation road map. A. T. Kearney & Efma. 2014.

3. Васильева Е. В. Дизайн-мышление: немного о подходе и много об инструментах развития креативного мышления, изучения клиентских запросов и создания идей. М.: Русайнс; 2019. 204 с.

4. Brown T. Change by design: How design thinking transforms organizations and inspires innovation. New York: HarperCollins Publishers; 2009. 272 p.

5. Kelley T., Kelley D. Creative confidence: Unleashing the creative potential within us all. New York: Barnes & Noble; 2013. 304 p.

6. Liedtka J., Ogilvie T. Designing for growth: A design thinking toolkit for managers. New York, Chichester: Columbia University Press; 2011. 248 p.

7. Clark T., Osterwalder A., Pigneur Y. Business model you: A one-page method for reinventing your career. New York: John Wiley & Sons; 2012. 256 p.

8. Ries E. The lean startup: How today's entrepreneurs use continuous innovation to create radically successful businesses. New York: Crown Business; 2013. 336 p.

9. Blank S. The four steps to the epiphany: Successful strategies for products that win. Berks County: K & S Ranch; 2014. 276 p.

10. Goldhill J. The age of omnichannel banking. Transform. URL: http://www.transformuk.com/wp-content/ uploads/2015/03/Transform-UK-The-Age-of-0mnichannel-Banking-Report.pdf (дата обращения: 10.02.2020).

11. Karpuzcu T. Impact of e-services on customer satisfaction. Saarbrücken: LAP Lambert Academic Publishing; 2011. 124 p.

12. Ramadan S. Omnichannel marketing: The roadmap to create and implement omnichannel strategy for your business. Charleston, SC: CreateSpace Independent Publ. Platform; 2016. 66 p.

13. Malhotra J. S. Multi-channel optical communication. Saarbrücken: Scholars' Press; 2014. 220 p.

14. Скиннер К. Цифровой банк. Как создать цифровой банк или стать им. Пер. с англ. М.: Манн, Иванов и Фер-бер; 2014. 320 c.

15. Inmon W. H. Building the data warehouse. New York: John Wiley & Sons Inc.; 2002. 428 p.

16. Поппендик М., Поппендик Т. Бережливое производство программного обеспечения: от идеи до прибыли. Пер. с англ. М.: Вильямс; 2010. 256 с.

17. Giorgini P., Rizzi S., Garzetti M. GRAnD: A goal-oriented approach to requirement analysis in data warehouses. Decision Support Systems. 2008;45(1):4-21. DOI: 10.1016/j.dss.2006.12.001

18. King B. Breaking banks: The innovators, rogues, and strategists rebooting banking. Singapore: John Wiley & Sons; 2014. 288 p.

19. Arican A. Multichannel marketing: Metrics and methods for on and offline success. Indianapolis, IN: Wiley Publishing; 2008. 312 p.

20. Соммервилл И. Инженерия программного обеспечения. Пер. с англ. М.: Вильямс; 2002. 624 с.

21. Meyer B. On to components. Computer. 1999;32(1):139-143. DOI: 10.1109/2.738312

22. Гамма Э., Хелм Р., Джонсон Р., Влассидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. Пер. с англ. СПб.: Питер; 2001. 368 с.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

23. Alexander C, Ishikawa S. at al. A pattern language: Towns, buildings, construction. New York: Oxford University Press; 1977. 1171 p. (Center for Environmental Structure Series. Vol. 2).

24. Евланов Л. Г., Кутузов В. А. Экспертные оценки в управлении. М.: Экономика; 1978. 133 с.

REFERENCES

1. Lewrick M., Link P., Leifer L. The design thinking playbook: Mindful digital transformation of teams, products, services, businesses and ecosystems. Hoboken, NJ: John Wiley & Sons; 2018. 352 p. (Russ. ed.: Lewrick M., Link P., Leifer L. Dizain-myshlenie. Ot insaita k novym produktam i rynkam. St. Petersburg: Piter; 320 p.).

2. Going digital: The banking transformation road map. A. T. Kearney & Efma. 2014.

3. Vasil'eva E. V. Design thinking: A little bit about the approach and a lot about the tools for creative thinking, studying client requests and creating ideas. Moscow: RuScience; 2019. 204 р. (In Russ.).

4. Brown T. Change by design: How design thinking transforms organizations and inspires innovation. New York: HarperCollins Publishers; 2009. 272 p.

5. Kelley T., Kelley D. Creative confidence: Unleashing the creative potential within us all. New York: Barnes & Noble; 2013. 304 p.

6. Liedtka J., Ogilvie T. Designing for growth: A design thinking toolkit for managers. New York, Chichester: Columbia University Press; 2011. 248 p.

7. Clark T., Osterwalder A., Pigneur Y. Business model you: A one-page method for reinventing your career. New York: John Wiley & Sons; 2012. 256 p.

8. Ries E. The lean startup: How today's entrepreneurs use continuous innovation to create radically successful businesses. New York: Crown Business; 2013. 336 p.

9. Blank S. The four steps to the epiphany: Successful strategies for products that win. Berks County: K & S Ranch; 2014. 276 p.

10. Goldhill J. The age of omnichannel banking. Transform. URL: http://www.transformuk.com/wp-content/ uploads/2015/03/Transform-UK-The-Age-of-Omnichannel-Banking-Report.pdf (accessed on 10.02.2020).

11. Karpuzcu T. Impact of e-services on customer satisfaction. Saarbrücken: LAP Lambert Academic Publishing; 2011. 124 p.

12. Ramadan S. Omnichannel marketing: The roadmap to create and implement omnichannel strategy for your business. Charleston, SC: CreateSpace Independent Publ. Platform; 2016. 66 p.

13. Malhotra J. S. Multi-channel optical communication. Saarbrücken: Scholars' Press; 2014. 220 p.

14. Skinner C. Digital bank: Strategies to launch or become a digital bank. Singapore: Marshall Cavendish Int. (Asia) Pte Ltd.; 2014. 300 p. (Russ. ed.: Skinner C. Tsifrovoy bank. Kak sozdat' tsifrovoy bank ili stat' im. Moscow: Mann, Ivanov and Ferber; 2014. 320 p.).

15. Inmon W. H. Building the data warehouse. New York: John Wiley & Sons Inc.; 2002. 428 p.

16. Poppendick M., Poppendieck T. Implementing lean software development: From concept to cash. Upper Saddle River, NJ: Addison-Wesley; 2006. 304 p. (Russ. ed.: Poppendick M., Poppendieck T. Berezhlivoe proizvodstvo programmnogo obespecheniya: ot idei do pribyli. Moscow: Williams; 2010. 256 p.).

17. Giorgini P., Rizzi S., Garzetti M. GRAnD: A goal-oriented approach to requirement analysis in data warehouses. Decision Support Systems. 2008;45(1):4-21. DOI: 10.1016/j.dss.2006.12.001

18. King B. Breaking banks: The innovators, rogues, and strategists rebooting banking. Singapore: John Wiley & Sons; 2014. 288 p.

19. Arican A. Multichannel marketing: Metrics and methods for on and offline success. Indianapolis, IN: Wiley Publishing; 2008. 312 p.

20. Sommerville I. Software engineering. 6th ed. Reading, MA: Addison-Wesley; 2000. 720 p. (Russ. ed.: Sommerville I. Inzheneriya programmnogo obespecheniya. Moscow: Williams; 2002. 624 p.).

21. Meyer B. On to components. Computer. 1999;32(1):139-143. DOI: 10.1109/2.738312

22. Gamma E., Helm R., Johnson R., Vlissides J. Design patterns: Elements of reusable object-oriented software. Reading, MA: Addison-Wesley Professional; 1994. 395 p. (Russ. ed.: Gamma E., Helm R., Johnson R., Vlissides J. Priemy ob"ektno-orientirovannogo proektirovaniya. Patterny proektirovaniya. St. Petersburg: Piter; 2001. 368 p.).

23. Alexander C, Ishikawa S. at al. A pattern language: Towns, buildings, construction. New York: Oxford University Press; 1977. 1171 p. (Center for Environmental Structure Series. Vol. 2).

24. Evlanov L. G., Kutuzov V. A. Expert evaluation in management. Moscow: Ekonomika; 1978. 133 p. (In Russ.).

ИНФОРМАЦИЯ ОБ АВТОРАХ / ABOUT THE AUTHORS

Елена Викторовна Васильева — доктор экономических наук, доцент, профессор кафедры бизнес-информатики, Финансовый университет, Москва, Россия

Elena V. Vasilieva — Dr. Sci. (Econ.), Assoc. Prof., Prof., Department of Business Informatics,

Financial University, Moscow, Russia

EVVasileva@fa.ru

Кирилл Сергеевич Солянов — ведущий бизнес-аналитик ООО «Глоубайт аналитические решения», Москва, Россия

Kirill S. Solyanov — Leading Business Analyst, GlowByte Analytical Solutions LLC, Moscow, Russia

KirSol4@yandex.ru

Татьяна Дмитриевна Коневцева — директор по управлению портфелем проектов, ПАО «ВТБ», Москва, Россия

Tat'yana D. Konevtseva — Project Portfolio Management Director, PJSC VTB BANK, Moscow, Russia

TKonevtseva@gmail.com

Заявленный вклад авторов:

Васильева Е. В. — постановка проблемы, разработка концепции статьи; обзор современных трендов, описание результатов и формирование выводов исследования.

Солянов К. С.—разработка и реализация базового набора компонентов и бизнес-объектов модели адаптивного банковского хранилища данных.

Коневцева Т. Д. — разработка архитектурных принципов создания единой фронтальной системы омника-нального банка.

Authors' declared contribution:

Vasilieva E.V.—problem definition, concept formation of the study; review of current trends, description of the results, conclusions.

Solyanov K. S.— concept of adaptive banking data warehouse, development and implementation of a basic set of components and business objects of the adaptive banking data warehouse model, graphical representation of the results.

Konevtseva T. D.— architectural principles for creating a unified front-end omnichannel banking system.

Статья поступила в редакцию 02.03.2020; после рецензирования 27.03.2020; принята к публикации 11.05.2020. Авторы прочитали и одобрили окончательный вариант рукописи.

The article was submitted on 02.03.2020; revised on 27.03.2020 and accepted for publication on 11.05.2020. The authors read and approved the final version of the manuscript.

i Надоели баннеры? Вы всегда можете отключить рекламу.