CC BY
31
программный инструментарии управления
продажами дополнительных услуг на рынке розничного кредитования
УДК 004.4
Сергей Александрович Краско,
аспирант кафедры Управления Знаниями и Прикладной Информатики в Менеджменте Московского государственного университета экономики, статистики и информатики (МЭСИ) Тел.: 8 (903) 723-29-32 Эл. почта: sakrasko@gmail.com
В статье излагаются основные вопросы проектирования инструментального средства реализации дополнительных услуг. Основное внимание сосредоточено на разработке эффективной архитектуры инструментального средства, а так же приведены основные концептуальные положения его реализации.
Ключевые слова: дополнительные услуги, архитектура, концептуальные положения, инструментальное средство, управление продажами.
Sergey A. Krasko,
PhD in Economics Student, the Department of Knowledge Management and Applied Informatics in Management, Moscow State University of Economics, Statistics and Informatics (MESI) Tel.: 8 (903) 723-29-32 E-mail: sakrasko@gmail.com
SALES MANAGEMENT SYSTEM FOR ADDITIONAL SERVICES ON THE RETAIL LENDING MARKET
The article presents the main issues of design sales management system for additional services on the retail lending market. Attention is concentrated on developing effective system architecture and conceptual provisions of the development.
Keywords: additional services, architecture, conceptual provisions, sales management system.
1. Введение
Рынок розничного кредитования является одним из наиболее динамично развивающихся рынков Российской федерации. В условиях жесткой конкуренции современные коммерческие банки вынуждены искать новые способы привлечения клиентов. На первый план выходят неценовые факторы, такие как качественный клиентский сервис. Это приводит к необходимости выбора новых, малоизученных, направлений развития деятельности на рынке розничного кредитования, среди которых можно выделить интенсификацию кросс-продаж дополнительных услуг. Под кросс-продажами дополнительных услуг понимается предложение банком клиенту, обладающему или только оформляющему тот или иной кредитный продукт, приобрести другие взаимосвязанные услуги, способные повысить привлекательность продукта или обеспечить более выгодные условия.
Рост рынка розничного кредитования диктует необходимость увеличения прибыли от реализации дополнительных услуг. При этом существующие подходы к реализации имеют ряд серьезных недостатков и требуют существенных трудозатрат со стороны сотрудников банка. Это приводит к тому, что сотрудники неохотно занимаются реализацией дополнительных услуг, и даже серьезное увеличение мотивации не помогает обеспечить значительное увеличение объемов продаж. Важной задачей для банков становится построение и использование эффективного инструментария управления продажами дополнительных услуг, отвечающего современным условиям.
2. Достоинства и недостатки существующих подходов к реализации дополнительных услуг
Существующие подходы к реализации дополнительных услуг на рынке розничного кредитования характеризуются частичной автоматизацией с помощью различного обособленного программного обеспечения, причем не только банковского, но и предоставляемого компаниями-поставщиками услуг. Использование такого программного обеспечения способствует повышению качества обработки информации на стороне поставщика, а также сокращению объема ручных работ в части взаимодействия с банком. Из плюсов для банка можно выделить отсутствие необходимости финансовых и операционных затрат на разработку и поддержку, а также возможность довольно быстрого старта продаж сразу после заключения договора с партнером.
В качестве основного недостатка следует отметить наличие большого количества неавтоматизированных работ, связанных с обработкой клиентских данных, что приводит к постоянному возникновению ошибок, существенно затрудняет процесс и увеличивает время, затрачиваемое сотрудником на продажу и оформление дополнительной услуги.
Обработка клиентских данных осуществляется непосредственно пользователями (сотрудниками банка) в продающих подразделениях. Несмотря на автоматизацию, сотрудникам приходится выполнять ряд ручных работ из-за невозможности интеграции программного обеспечения партнеров с банковской информационной системой. Например, сотрудники вынуждены осуществлять проверку и заполнение одних и тех же клиентских данных сразу в нескольких системах, заполнять печатные формы, рассчитывать суммы комиссии, вести реестры продаж и выполнять другие трудоемкие операции. Возникновение ошибки на одном из этапов процесса, как правило, приводит к необходимости полного переоформления дополнительной услуги или вовсе к отказу клиента от оформления. В среднем на реализацию дополнительной услуги уходит около 25-30 минут. Всё вышеизложенное в результате приводит к тому, что сотрудники просто не хотят заниматься продажей дополнительных услуг и даже предельное увеличение мотивации не позволяет существенно увеличить объемы продаж.
Можно сделать вывод, что на текущий момент при реализации дополнительных услуг на рынке розничного кредитования банки сталкиваются с рядом технических и методических трудностей, при этом существующие инструмен-
тальные средства не обладают требуемой гибкостью и функциональностью. Анализ существующих подходов к реализации дополнительных услуг показал необходимость разработки инструментального средства, учитывающего недостатки существующих подходов и увеличивающего эффективность процессов реализации дополнительных услуг.
3. Концептуальные положения разработки инструментального средства реализации дополнительных услуг.
Анализ существующих подходов к построению банковских информационных систем поддержки продаж позволил сформировать новый подход к построению систем, автоматизирующих продажи дополнительных услуг и основанный на использовании сервисно-ориентированной архитектуры. Под сервисом понимается определенный программный компонент, который предоставляет определенную функциональность и правила, по которым должно осуществляться взаимодействие с этим компонентом [2].
Формализация процессов реализации дополнительных услуг [4] позволила сформировать основные требования к банковской информационной системе, обеспечивающей поддержку операций по продаже дополнительных услуг. Жизненный цикл дополнительной услуги (Рисунок 1) условно разбит на три этапа:
1. Регистрация. Этап регистрации состоит из ввода данных, расчета стоимости, проверки введенных данных на возможность регистрации услуги, а также генерации и подписания договора.
2. Оплата. На этом этапе осуществляется проверка возможности оплаты, непосредственно списание денежных средств со счета клиента, а также расчет, списание комиссий и перевод средств поставщику.
3. Учет. В рамках этого этапа предусмотрена генерация реестров оплаченных дополнительных услуг для обмена с поставщиками дополнительных услуг, формирование отчетов, а также должна осуществляться автоматическая пролонгация.
Обработку дополнительной услуги на разных стадиях обеспечивает две группы подразделений банка (аналогично стадиям жизненного цикла услуги): фронт-офис и бэк-офис. В отличие от существующих подходов предлагается свести к минимуму количество операций, выполняемых сотрудниками вручную за счет интеграции разрабатываемой системы с существующими системами всех уровней. Сотрудниками фронт-офиса по-прежнему будет выполняться заполнение заявки, но уже с использованием существующих в информационной банковской системе данных. На сотрудниках бэк-офиса необходимо оставить только функцию формирования реестров платежей и взаимодействие с партнерами по ним. Все остальные операции должны быть автоматизированы.
Анализ процессов реализации дополнительных услуг на рынке розничного кредитования, а также анализ подходов к построению банковских информационных систем позволил сформулировать следующие концептуальные положения построения инструментального средства реализации дополнительных услуг:
Рис. 1. Жизненный цикл дополнительной услуги
1. Принцип непрерывности цепочки операций - непрерывность цепочки операций позволит снизить затраты на исполнение каждой операции. Как следствие, это приводит к увеличению скорости выполнения операций, а также к сокращению количества ошибок, обусловленных человеческим фактором. Рост скорости выполнения операций позволит банку увеличить объемы продаж дополнительных услуг.
2. Принцип отдельных программных компонентов - различные участки бизнес процесса выделяются в обособленные программные компоненты со своими интерфейсами. При этом существенно увеличивается скорость внедрения изменений, за счет предоставления возможности разработки и доработки программных модулей без ущерба для всей системы, сохраняя совместимость на уровне интерфейсов (например, добавление нового механизма расчета стоимости будет происходить без внесения существенных изменений в архитектуру). Также эти компоненты можно будет в дальнейшем использовать в других системах.
3. Принцип множественности интерфейсов - в инструментальном средстве должны быть реализованы интерфейсы для интеграции с другими программными средствами, обеспечивающими процессы банка. Без тесной интеграции с другими банковскими информационными системами невозможно достигнуть эффективной автоматизации процесса и как следствие увеличить скорость выполнения операций и снизить количество ошибок.
4. Принцип единого окна - для достижения наибольшей эффективности сотрудники банка должны работать с единой системой обслуживания клиентов. Соответственно разрабатываемое инструментальное средство должно быть тесно интегрировано с единой системой обслуживания таким образом, что бы работа с дополнительными услугами осуществлялась через нее. Это позволит существенно упростить процесс реализации дополнительных услуг, ведь сотрудникам не придется постоянно переключаться между различными программными средствами для поиска информации и оформления дополнительной услуги. Также это позволит облегчить процесс консультации и обслуживания клиентов, так как вся необходимая информация по дополнительным услугам будет представлена в
Рис. 2. Архитектура инструментального средства реализации дополнительных услуг
едином привычном интерфейсе системы обслуживания.
5. Принцип глобальной актуальности справочной и обрабатываемой информации - в разрабатываемом инструментальном средстве должна использоваться актуальная информация из центральных банковских справочников по всем клиентам и продуктам на всех участках жизненного цикла дополнительной услуги. Это позволит сократить количество ошибок, обусловленных использованием неактуальных или некачественных данных и, как следствие, уменьшить операционные расходы на сопровождение процессов реализации дополнительных услуг.
6. Принцип контролируемости и измеримости - должна быть реализована возможность учета и измерения времени выполнения всех бизнес операций, осуществляемых в инструментальном средстве. Это позволит облегчить построение аналитики по продажам дополнительных услуг, что в свою очередь облегчит управление моти-вационной программой по продажам.
7. Принцип универсальности - добавление новых видов дополнительных услуг должно происходить путем внесения необходимых настроек и без существенных доработок инструментального средства. В результате время, затрачиваемое на внедрение новых видов дополнительных услуг должно существенно сократиться.
4. Архитектура инструментального средства реализации дополнительных услуг.
Инструментальное средство реализации дополнительных услуг должно быть разделено на две части - клиентская и серверная. По логической функциональности клиентская часть исполняет функции фронт-офиса, а серверная - бэк-офиса. К клиентской части относятся графические интерфейсы, которые должны предоставлять возможность работы сотрудников и клиентов с дополнительными услугами и должны быть реализованы в существующих системах обслуживания клиентов. Серверная часть разрабатываемого инструментального средства функционирует во внутренней сети банка и обеспечивает автоматизацию основных процессов жизненного цикла дополнительных услуг: проверку возможности оформления, расчетов сроков действия и стоимости услуги, проверку возможности оплаты, оплату,
и периодические процессы оплаты и пролонгации. По возможности серверная часть должна быть реализована на одной платформе с функционирующей автоматизированной банковской системой (АБС), что обеспечит высокую производительность системы и наиболее эффективную интеграцию с существующими процессами розничного кредитования. Соединение клиентской и серверной части обеспечивается через внутреннюю сеть банка и интернет.
Архитектура инструментального средства реализации дополнительных услуг (рисунок 2) обусловлена предъявляемыми банками требованиями и описанными концептуальными положениями. Наиболее интересной и важной задачей является процесс регистрации дополнительной услуги, рассмотрим его более подробно.
Процесс оформления дополнительной услуги инициируется пользователем в соответствующем графическом интерфейсе клиентской части. Для достижения наиболее эффективной автоматизации, проверка клиентских данных должна осуществляться еще до начала заполнения полей экранной
формы оформления услуги. Сервис поиска доступных услуг на основании клиентских данных через сервис проверки осуществляет отбор дополнительных услуг, которые действительно можно оформить выбранному клиенту с учетом успешного прохождения всех проверок.
На основании параметров выбранной услуги, в графическом интерфейсе оформления услуг формируется экранная форма, где отображаются блоки полей необходимые для заполнения, а также информация о клиенте и оформляемой услуге. Необходимые поля (продукт, счет, тариф и т.д.) должны заполняться с использованием уже существующих клиентских данных из АБС. Взаимодействие системы обслуживания и АБС должно осуществляться посредством веб сервисов.
При необходимости расчета стоимости (если цена услуги не фиксированная), из клиентской части осуществляется запрос в сервис расчета стоимости. При получении запроса, сервис расчета стоимости на основании параметров кредитного продукта и тарифа из соответствующих систем,
а также типа услуги и данных клиента, осуществляет расчет точной стоимости дополнительной услуги. Точная стоимость и сроки действия передаются в клиентскую часть, и отображается в форме оформления дополнительной услуги.
После согласия клиента с точной стоимостью услуги пользователь заполняет оставшиеся специфические поля, необходимые для оформления услуги и нажимает кнопку «печать». Из клиентской части формируется запрос в сервис печати для формирования печатной формы документа (предусмотренного оформляемой услугой - заявления, полиса, договора и т.д.). Сервис печати, в соответствии с выбранным типом дополнительной услуги, а также с введенными на экранной форме данными, формирует печатную форму документа, которая возвращается в клиентскую часть. Пользователь должен распечатать получившийся документ, а клиент должен его подписать.
После этого пользователь должен подтвердить факт подписания документа. При подтверждении факта подписания документа, из клиентской части осуществляется запрос на регистрацию дополнительной услуги в сервис регистрации. Сервис регистрации дополнительных услуг сначала формирует запрос в сервис проверки. Сервис проверки, в свою очередь, в зависимости от параметров услуги определяет необходимость выполнения той или иной конкретной проверки и осуществляет все необходимые проверки клиентских данных, а также проверку возможности оплаты. В случае возникновения ошибки, ее описание через сервис регистрации возвращается в графический интерфейс клиентской части. Процесс оформления прекращается.
При успешном прохождении проверок сервис регистрации через сервис ввода данных осуществляет запись дополнительной услуги и всех ее параметров в централизованное хранилище. В случае, если параметрами дополнительной услуги оплата в момент регистрации не предусмотрена, то дополнительная услуга сохраняется в активном состоянии, а результат успешной регистрации через сервис регистрации передается назад и отображается в клиентской части.
Если же в момент регистрации предусмотрена оплата, то после ус-
пешного прохождения проверок сервисом регистрации вызывается сервис оплаты. Сервис оплаты, на основе параметров дополнительной услуги и схемы бухгалтерского учета определят все проводки и платежные документы, которые необходимо осуществить, после чего вызывает систему расчетов с необходимыми параметрами для их формирования. Система расчетов формирует все необходимые платежные документы, предусмотренные схемой бухгалтерского учета, после чего возвращает в сервис оплаты результаты списания комиссий с номерами проводок и платежных документов. Сервис оплаты возвращает полученные данные в сервис регистрации, который в свою очередь через сервис ввода данных сохраняет данные о совершенной оплате и только тогда присваивает дополнительной услуге активный статус. Стоит отметить, что в случае возникновения ошибки в процессе оплаты сервис регистрации также транслирует ошибку в клиентскую часть, а сама услуга из хранилища удаляется.
Результат успешной регистрации услуги сервисом регистрации возвращается в графический интерфейс клиентской части. На этом процесс регистрации дополнительной услуги можно считать завершенным.
Стоит отметить, что процесс изменения данных о дополнительной услуге является схожим. Например, при необходимости отключения дополнительной услуги, она выбирается пользователем из профиля клиента во фронт системе обслуживания. Следует понимать, что в соответствии с описанными ранее требованиями при открытии клиентской сессии должен вызываться сервис чтения, который предоставляет информацию по всем дополнительным услугам конкретного клиента. При нажатии на кнопку «отключить услугу» через сервис регистрации осуществляется проверка параметров, при необходимости выполняется оплата, после чего выбранная услуга деактивируется.
Не менее важным для рассмотрения является диспетчер операций, который отвечает за автоматизацию остальных процессов жизненного цикла услуги, а также за синхронизацию с банковскими процедурами закрытия дня.
В результате анализа жизненного цикла и процессов реализации дополнительных услуг было выявлено, что различные автоматические операции
должны происходить в разные промежутки времени, а результат выполнения одних является пререквизитом для других. Логично предположить, что определение необходимости продления услуги на новый срок должно проходить поздно вечером в последний день ее действия, тогда как оплата услуги на следующий срок должна осуществляться ранним утром, чтобы в случае возникновения ошибки услуга не считалась активной. В соответствии с концепциями нужно учитывать также внешний фактор - банковскую процедуру закрытия дня. Во время этой процедуры функционирует большинство автоматических процессов различных систем банка, в том числе и процессы кредитного модуля. Соответственно, что бы иметь актуальную информацию по параметрам кредитного продукта клиента необходимо, чтобы основные процедуры диспетчера операций запускались после кредитных. Логическая архитектура диспетчера операций представлена на рисунке 3.
Диспетчер операций представляет собой командный сервис, запускаемый по расписанию несколько раз во время работы банковской процедуры закрытия дня. Под командным сервисом подразумевается сервис, который будет осуществлять по определенному алгоритму вызов остальных программных компонентов системы в автоматическом режиме.
Важно отметить, что для построения эффективной архитектуры, а также для корректного выполнения процессов жизненного цикла услуг необходимо разработать отдельные сервисы, которые будут отвечать за логику отбора параметров дополнительных услуг и параметров платежей, необходимых для работы основных сервисов системы. Получается, что диспетчер операций по расписанию запускает отдельные сервисы, отвечающие за отбор данных для автоматических операций, которые в свою очередь уже через основные сервисы системы обеспечивают выполнение всех операций в рамках жизненного цикла дополнительных услуг.
Предусмотрено два режима - две фазы запуска диспетчера операций на разных фазах процедуры закрытия дня: вечер и раннее утро.
В день Т, поздним вечером, из диспетчера операций должен запускаться сервис пролонгации дополнительных услуг. Сервис пролонгации должен
Рис. 3. Логическая архитектура диспетчера операций
отобрать и обработать все действующие дополнительные услуги, у которых последний день действия равен дню Т. При отсутствии возможности пролонгации или наличии отказа от пролонгации сервис должен деак-тивировать дополнительную услугу через соответствующий сервис ввода данных. Если же для услуги предусмотрена автоматическая пролонгация, то сервис должен в соответствии с
тарифами рассчитать дату следующего платежа по дополнительной услуге.
В день Т+1, ранним утром, строго после отработки автоматических процедур кредитного модуля, из диспетчера операций должно последовательно вызываться несколько сервисов. В первую очередь запускается сервис синхронизации с кредитным модулем, который по все действующим услугам, где расчет параметров зависит
от кредитного продукта, производит актуализацию параметров кредитных продуктов. Это необходимо для определения корректных дат и сумм оплаты, когда они напрямую зависят от параметров кредитного продукта клиента. Например, для определения даты оплаты услуги, в случае необходимости оплаты в дату очередного платежа по кредиту.
После сервиса синхронизации с кредитным модулем должен запускаться сервис отбора дополнительных услуг. Этот сервис должен отобрать все услуги, по которым в текущий день (Т+1) должно произойти списание комиссии со счета клиента, после чего для каждой последовательно вызвать сервисы расчета стоимости, проверки, оплаты и ввода данных. Сначала в соответствии с актуальными тарифами необходимо произвести расчет (через сервис расчета стоимости) и корректировку (через модуль ввода) стоимости, а также сроков действия. После корректировки стоимости и сроков действия, через сервис проверки, по этим услугам должны быть осуществлены все соответствующие проверки. В случае не успешного прохождения проверки услуга должна деактивироваться через сервис ввода. При успешном прохождении проверки для услуги вызывается сервис оплаты. Сервис оплаты, на основе параметров дополнительной услуги и схемы бухгалтерского учета определяет все необходимые проводки и платежные документы, после чего вызывает систему расчетов с необходимыми параметрами для их формирования. Система расчетов формирует все необходимые платежные документы, предусмотренные схемой бухгалтерского учета, после чего передает в сервис активации результаты списания комиссий с номерами проводок и платежных документов в сервис ввода, который их сохраняет.
После сервиса отбора услуг должен отработать сервис перевода средств поставщикам дополнительных услуг. Этот сервис в разрезе каждого типа дополнительных услуг, в соответствии со схемой бухгалтерского учета, осуществляет расчет суммы для перевода поставщику и через систему расчетов формирует все необходимые платежные документы.
После чего аналогично должен отработать сервис взимания комиссии. Этот сервис в разрезе каждого типа дополнительных услуг, в соответст-
Рис. 4. Логическая схема доступа к хранилищу
вии со схемой бухгалтерского учета, осуществляет расчет суммы комиссии банка, которую необходимо списать с поставщика, и через систему расчетов формирует все необходимые платежные документы.
В рамках диспетчера операций также функционирует сервис информирования. Который должен отбирать все услуги, для которых возможно и активно оповещение, с будущей датой оплаты, например +3 дня. По каждой такой услуге с помощью систем информирования сервис должен создать оповещение для клиента с рекомендацией внесения денежных средств на сумму комиссии для оплаты следующего периода действия дополнительной услуги.
Следуя выводам, изложенным ранее, все дополнительные услуги должны храниться в централизованном хранилище. Также все дополнительные услуги клиентов должны быть доступны различным банковским информационным системам, например, таким как системы обслуживания или системы построение отчетности. Для эффективной интеграции систем, согласно принципам построения систем на основе сервисно-ориентированного подхода, прямой доступ в хранилище дополнительных услуг для внешних систем должен быть ограничен. Иначе при добавлении новых сущностей дополнительных услуг или изменении структуры, пришлось бы дорабатывать еще и все внешние системы, работающие с хранилищем.
Хоть запись данных может осуществляться только сервисами самого инструментального средства, все равно для этой цели должен быть разработан отдельный независимый сервис ввода данных. Это позволит обеспечить корректность заполнения параметров и структуры дополнительной услуги. Через сервис ввода данных, внутренними сервисами будет осуществляться запись и изменение дополнительных услуг.
Также необходимо разработать отдельный сервис чтения для доступа к данным из внешних систем, который по запросу будет осуществлять отбор и преобразование данных в формат XML. Логическая схема работы с хранилищем изображена на рисунке 4.
Для соблюдений концептуальных положений, описанных ранее в разрабатываемом инструментальном средстве необходимо реализовать универсальный сервис настроек дополнительных услуг. Через этот сервис сотрудниками бэк-офиса банка будет осуществляться добавление новых типов дополнительных услуг, а также изменение параметров существующих. Настройки и сущности всех видов дополнительных услуг должны храниться в отдельных настроечных таблицах, а в сервисе должны быть реализованы четкие правила использования этих настроек во избежание ошибок, вызванных некорректной настройкой услуг. Интерфейс работы с сервисом можно разработать в виде отдельного веб приложения, работающего с сервисом
через соответствующие веб сервисы. Но для удобства работы сотрудников бизнес подразделений с настройками, лучше всего реализовать интерфейс настроек в существующей системе обслуживания клиентов. Использование сервиса настройки позволит существенно снизить время, затрачиваемое на добавление новых видов дополнительных услуг. Для добавления услуг общего типа потребуется лишь внести изменения в настройки, а также создать печатные формы документов в системе печати.
5. Заключение
Описанный подход к построению инструментального средства реализации дополнительных услуг позволяет существенно снизить временные издержки на каждую операцию, увеличить число обрабатываемых операций. Также описанный подход интегрирует инструментальное средство с существующими банковскими информационными системами в единое целое, повышая эффективность реализации дополнительных услуг и за счет использования актуальной информации сокращая количество ошибок возникающих при реализации к минимуму. Кроме того, эффективная декомпозиция единой системы на взаимодействующие между собой сервисы позволяет изолировать бизнес функции и свести к минимуму влияние возможных изменений одного направления на остальные.
В итоге мы получаем не только эффективно работающее инструментальное средство позволяющее автоматизировать процессы жизненного цикла дополнительных услуг и существенно сократить время их обработки, но и инструментальное средство, стоимость доработки которого значительно ниже, а скорость внесения изменение и доработки значительно выше относительно монолитных информационных систем.
Литература
1. Уринцов А. И. Многоуровневые экономические информационные системы. - Москва : Московский международный институт эконометрики, финансов и права, 2003.
2. Биберштейн Н. Компас в мире сервис ориентированной архитектуры ^ОА): ценность для бизнеса, планирование и план развития. - Москва : КУДИЦ-ОБРАЗ, 2007.
3. Дик В.В. Учебник Банковские информационные системы: внутренний и внешний аспект. - Москва: Маркет DS, 2006.
4. Краско С.А. Некоторые вопросы реализации дополнительных услуг на рынке розничного кредитования. -Москва: Журнал Интеграл, 2012
5. Erl Thomas SOA Design Patterns [Книга]. - [б.м.] : Prentice Hall, 2008
6. Бушманова М.В., Машинсон Б.В. Классификация банков - лидеров потребительского кредитования // Экономика, статистика и информатика. Вестник УМО. 2007. № 3. С. 71-75.
7. Панова Т.А. К вопросу о расширении потребительского креди-
тования // Экономика, статистика и информатика. Вестник УМО. 2010. № 3. С. 48-52.
References
1. Urintcov A. I. Multi-level economic information systems. -Moskva : Moskovskii mezhdunarod-nyi institut ekonometriki, finansov i prava, 2003.
2. Bibershtein N. Compass in the world service-oriented architecture (SOA): Business Value, Planning, and Development Plan. - Moskva : KUDITC-OBRAZ, 2007.
3. Dik V.V. Textbook Banking Information System: the internal and
external dimension. - Moskva: Market DS, 2006.
4. Krasko S.A. Some questions of the additional services on the retail lending market. - Moskva: Zhurnal Integral, 2012
5. Erl Thomas SOA Design Patterns [Kniga]. - [b.m.] : Prentice Hall, 2008.
6. Bushmanova M.V., Mashinson B.V. Classification of banks - leaders in consumer lending // Ekonomika, statistika i informatika. Vestneyk UMO. 2007. № 3. S. 71-75.
7. Panova T.A. On the question of the expansion of consumer credit // Ekonomika, statistika i informatika. Vestneyk UMO. 2010. № 3. S. 48-52.
