Финансовая сфера

Банковское обозрение


  • Безупречный look операций по вкладам
06.05.2016 Аналитика

Безупречный look операций по вкладам

Разработчики RS-Retail V.6 — системы автоматизации розничного банковского обслуживания из состава ИБС RS-Bank V.6 — завершили портацию на web-интерфейс полного спектра операций по вкладам, производимых в присутствии клиента (новое название — АРМ «Единое окно»), с одновременным переводом данной функциональности на новый механизм операций. При этом делалась ставка не только на дизайн и юзабилити экранных форм, но и на реализацию операций как исполняемых процессов, описанных в нотации BPMN


Подход к организации рабочего места операциониста

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

В стремлении к универсальности, нам удалось в АРМ «Единое окно» объединить некоторые из прежних операций. Пример — обновленная операция «Списание со счета на счет» (рис. 1), предусматривающая разные варианты списания с одного счета клиента на другой, причем эти счета могут быть в разных валютах, а конверсия списываемой суммы выполняется по настроенным курсам.

 

Рис. 1. Параметры операции «Списание со счета на счет»

 

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

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

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

 

Рис. 2. Форма для установки сроков по договору открытия вклада

 

Теме функциональности «Единого окна» не так давно была посвящена отдельная статья, так что подробно на этом мы останавливаться не будем. Упомянем лишь самые последние новшества модуля. Начнем с — подтверждения операций вторым лицом. Нужно заметить, что необходимость такого подтверждения может быть настроена для любых операций системы, требующих дополнительного мониторинга со стороны контролирующего работника. В этом случае операционист формирует запрос к супервизору на разрешение продолжить выполнение совершаемого действия (рис. 3). Запрос отправляется на рабочее место контролирующего работника и ожидает там его вердикта (рис. 4). Чтобы контролирующий работник мог принять осознанное решение, в запросе присутствует краткая информация о выполняемом действии: ФИО клиента, его особенности, сумма операции, реквизиты операциониста, обслуживающего этого клиента и т.п. Если супервизор разрешает выполнение требующей его подтверждения операции, ответ контролирующего работника поступает к проводящему операцию пользователю, и выполнение операции автоматически продолжается. В случае запрета супервизора на проведение выбранного действия операция отменяется.

 

Рис. 3. Рабочее место выполняющего операцию пользователя

 

Рис. 4. Рабочее место супервизора

 

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

 

Рис. 5. Список приостановленных операций клиента

 

Выполнение операций со статусом «Разрешена» можно продолжить с того места, откуда ее выполнение было прервано ранее. Но теперь сумма операции уже становится фиксированной, и пользователь не может ее изменить, поскольку Финансовый мониторинг разрешил продолжить текущую операцию именно на ту сумму, что указана в документе.

Из нефинансовых операций, выполняемых по вкладам и текущим счетам клиентов, при встраивании в «Единое окно» существенных изменений претерпела функциональность по работе с наследством. При переводе на web-интерфейс было обнаружено, что прежняя реализация не позволяет «красиво» поддержать требования законодательства по данному вопросу, а часть возможностей (например, отказ от завещания) и вовсе утратила актуальность. С другой стороны, в настоящее время существует четкое разграничение волеизъявлений, составленных при жизни владельца счета (записи типа «Завещание»), и нотариально подтвержденных документов о вступлении в наследство (записи типа «Наследство»), по которым и должна осуществляться выплата назначенных долей наследуемых счетов наследникам. Поэтому было решено не переносить в новый интерфейс заведомо устаревшие принципы, а предоставить нашим клиентам более современное виденье данного вопроса.

Теперь работа с завещаниями и наследством сводится к следующему:

• При жизни владелец счета/вклада может оформить завещание. Как и раньше, здесь соблюдается тайна завещания (реквизиты наследника можно указывать вручную, наследник никак не узнает о том, что ему завещан какой-либо вклад). Такие оформленные завещания носят исключительно информационный характер – выдача долей по ним после смерти владельца производиться не будет, поскольку все выдачи должны вестись по документам от нотариуса.

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

• Помимо этого в системе реализована возможность совершать разовые выплаты со счетов/вкладов умершего клиента.

Функциональность доверенностей и длительных поручений также переведена на web-интерфейс, но в «Едином окне» она дополнена возможностью прикреплять скан-копии документов к соответствующим записями.

Как уже было упомянуто, большое внимание уделили эргономическим характеристикам «Единого окна».

В частности, были внесены изменения в область поиска клиента (рис. 6).

 

Рис. 6. Окно для поиска клиента

 

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

Как приятное дополнение — информация о клиенте дополнена теперь его фотографией и подписью.

Еще одна эргономическая доработка, которая была выполнена за последнее время, – это «раскраска» дерева продуктов клиента (рис. 7). На первый взгляд такая доработка может показаться незначительной, но на деле она обеспечивает несомненное удобство в использовании. Каждому виду продуктов соответствует свой цвет, и пользователю легче ориентироваться в дереве, выполняя поиск нужного продукта или его прикладного объекта определенной этой цветовой области.

Если продукт связан всего с одним относящимся к нему прикладным объектом, нет необходимости располагать их на разных уровнях дерева – логичнее объединить на одном уровне. Это позволит оградить операциониста от лишних кликов мыши и тем самым ускорить процесс обслуживания клиента.

 

Рис. 7. Раскраска дерева продуктов

 

Новые инструменты технолога и IТ-специалиста

В EasyWin-версии системы, не были разделены уровни представления данных и бизнес-логики, что не позволяло использовать эту реализацию с web-интерфейсом. Поэтому разработка «Единого окна» стала отличным поводом, чтобы приступить к созданию нового механизма операций (МО) RS-Retail. При этом мы ставили перед собой цель: создать универсальный механизм описания и реализации операций независимо от типа услуги (или нескольких типов услуг), которую конкретная операция обслуживает.

Главная и, пожалуй, самая яркая особенность нового МО — трактовка каждой операции как бизнес-процесса, который описывается в нотации BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов). Какие преимущества мы при этом получаем?

Во-первых, мы имеем общую технологию разработки операций, не зависящую от типа услуги (вида операции). Каждая операция RS-Retail V.6 изображается в графическом редакторе по одним и тем же правилам. Сложные и повторяющиеся наборы действий выделяются в подпроцессы — составные действия, которые содержат внутри себя собственные диаграммы процессов (рис. 8).

 

Рис. 8. Пример подпроцесса, описанного аналитиком

 

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

 

Рис. 9. Список BPMN-приложений

 

Диаграмма бизнес-процесса сохраняется в формате XPDL (англ. XML Process Definition Language, язык описания определений и реализаций процессов, является международным стандартом). Исполнение бизнес-процесса сводится к выполнению экземпляра Java-класса, созданного при компиляции XPDL, и вызова его методов с передачей в него входных параметров процесса.

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

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

При переносе вкладных операций в новый интерфейс количество бизнес-процессов оказалось меньше, чем количество операций. Часть операций была объединена в одном бизнес-процессе, а для некоторых операций было создано несколько бизнес-процессов (табл. 1).

Таблица 1. Соответствие старых вкладных операций и бизнес-процессов нового механизма операций

Старые вкладные операции

Соответствующие им бизнес-процессы в новом МО
Вид Название

4

Расход

Списание наличных с вкладного счета

3

Дополнительный взнос

Зачисление наличных на вкладной счет

65

Переводом вклада

Перечисление средств с вкладного счета на вкладной счет

80

Конверсия валют

1

Открытие наличными

Открытие вклада

63

Списание по поручению

Безналичное списание с вкладного счета

66

В свое подразделение

67

В чужое подразделение

10

Закрытие наличными

Вклады: Закрытие с выдачей наличными

81

Закрытие безналичными

Вклады: Закрытие с перечислением по реквизитам
Вклады: Закрытие с перечислением на вкладной счет

96

Закрытие переводом

Вклады: Закрытие с перечислением по реквизитам

6

Выдача процентов

Выдача процентов с вклада

99

Выдача наследства

Разовая выплата со счетов умершего вкладчика
Выплата наследства по вкладу

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

Вот, к примеру, одна из распространенных общих функций — контроль операции службой финансового мониторинга. Сам контроль выполняется в специальном модуле АБС, но для его инициирования и обработки результатов необходимо произвести ряд действий в прикладном АРМ. В «Едином окне» для этого имеется общий для всех операций подпроцесс «Контроль ФМ для вкладных операций», который вызывается во всех операциях, подлежащих контролю. Этот подпроцесс выполняет стандартные действия, требующиеся для организации контроля как автоматически, так и по инициативе операциониста. При необходимости он организует приостановку операции для отложенного принятия решения, в этом случае бизнес-процесс прекращает выполнение, но все его параметры сохраняются, чтобы его можно было возобновить с места остановки.

Для всех вкладных операций, предусматривающих проверку ФМ, рекомендована общая схема организации этой функциональности (рис. 10).

 

Рис. 10. Схема организации ФМ в бизнес-процессе (схема приводится с максимальным сокращением действий, не относящихся в ФМ)

 

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

 

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

 

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

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

 

Рис. 12. Общая схема организации подпроцесса проводки при вкладной операции

 

Заметим, что все действия подпроцесса объединены в транзакцию, то есть выполняется «либо все, либо ничего».

Действие «Оформление операции» регистрирует новую операцию в системе.

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

Действие «Вклады: Проценты после операции» обеспечивает расчет процентов по выполненной операции.

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

1) формирует РДД по списку шаблонов РДД из прикрепленной к подпроцессу цепочки шаблонов;

2) по сформированным документам создаются записи внутреннего учета («регистры аналитического учета»).

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

Бизнес-процесс, описывающий полное выполнение операции, сам может выступать подпроцессом для другого бизнес-процесса. Это бывает необходимо, когда некоторая операция является частью другой, более обширной операции (т.е. когда один бизнес-процесс должен полностью выполнить другой бизнес-процесс). Например, бизнес-процесс «Выплата наследства по вкладу», описанный в документе «002336_008_ЧТЗ_МО_БП_Вклады_ВыплатаНаследства», может вызвать один из шести подпроцессов, которые выполняют разные операции и при других обстоятельствах сами вызываются из «Единого окна» как независимые операции:

1) «Списание наличных с вкладного счета»;

2) «Перечисление средств с вкладного счета на вкладной счет»;

3) «Безналичное списание с вкладного счета»;

4) «Вклады: Закрытие с выдачей наличными»;

5) «Вклады: Закрытие с перечислением на вкладной счет»;

6) «Вклады: Закрытие с перечислением по реквизитам».

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

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

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

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

 

Рис. 13. Таблица принятия решений бизнес-правила «Вычисление платы за выполнение вкладной операции»

 

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

Реализованный в RS-Retail V.6 универсальный механизм описания операций обеспечивает целый ряд преимуществ для пользователей системы:

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

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

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






Сейчас на главной

ПЕРЕЙТИ НА ГЛАВНУЮ