Как уменьшить операционные риски, связанные с человеческим фактором?

Новое в продуктах
8593
0
Елена Плеханова, руководитель группы аналитиков проекта RS-Securities V.6 департамента банковского ПО RS-Bank, R-Style Softlab

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

Помочь банку снизить операционные риски, связанные с человеческим фактором, призван «Монитор событий» — специальная компьютерная программа, которая напомнит пользователю о наступлении какого-либо события и проконтролирует его обработку.



Представляем «Монитор событий»!

Компания R-Style Softlab разработала в рамках АБС RS-Bank V.6 специальный модуль, получивший название «Монитор событий». Он отражает все события, назначенные для исполнения конкретному сотруднику в текущем дне, с указанием их статуса (требует ли событие обработки, или она уже успешно завершена).

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

Следить за событиями — легко, удобно, просто!

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

«Монитора событий» для пользователя собрал все эти дела в единой панели (рис. 1).

Рис 1.jpg
Рис. 1. Интерфейс «Монитора пользователя»

Здесь пользователь, в нашем случае специалист по ценным бумагам, видит список всех событий, назначенных ему для исполнения сегодняшним днем (как то: погашение купонов, погашение выпусков ц/б, выплата дивидендов, расчет комиссий и прочее), а также статусы этих событий и время последней актуализации статусов. Не выходя из панели «Монитора», он следит за изменением статусов событий, вызывает функции обработки, контролирует результаты выполненных действий и повторно запускает обработку событий — после исправления ошибок или при появлении новых необработанных объектов.

Причем любая из этих операций выполняется путем нажатия соответствующей кнопки в панели инструментов.

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

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

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

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

Возможности «Монитора» для руководителя или контролирующего сотрудника

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

Рис 2.jpg
Рис. 2. Интерфейс «Системного монитора»

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

Чтобы все работало

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

Давайте рассмотрим подробно, шаг за шагом, как настраиваются события для «Монитора».

Первое, что нужно сделать, — настроить справочник событий. Это самый трудоемкий этап, правда, выполняется он лишь однажды (в рамках проекта внедрения) совместными усилиями сотрудников компании-разработчика и банка-заказчика.

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

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

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

И только если пользователи, предположим, хотят рассылать клиентам поздравления с днем рождения, то такое событие надо описать и реализовать.

Но вернемся к настройке. Вот как выглядит панель, в которой задаются основные параметры для события (рис. 3).

Рис 3.jpg
Рис. 3. Панель для настройки параметров события

Для каждого события необходимо задать следующие параметры: 
  1. Сотрудник или сотрудники (в терминах системы — «пользователи»), которым поручена обработка события. 
  2. Алгоритм проверки включения события в «Монитор» либо периодичность включения. Алгоритм реализуется в макропрограмме и может основываться на проверке состояния или наличия абсолютно любых объектов системы или внешних объектов. Следует учитывать, что для некоторых событий необходимость обработки может появляться в течение дня после исполнения других действий. Например, необходимость выполнить учет по сделкам возникает не в начале дня, когда формируется список событий «Монитора», а только после появления сделок в системе. Поэтому большое количество аналогичных событий включается в монитор без дополнительных проверок, а только исходя из заданной периодичности, что позволяет не проводить обновление «Монитора» в течение дня. Периодичность задается видом календарной даты — рабочий день, календарный день, последний рабочий день месяца и т.п. 
  3. Алгоритм проверки исполнения, то есть макрофункция, которая проверяет наличие необработанных объектов для события или, иными словами, необходимость обработки события. Если требуется всегда видеть актуальное состояние статуса события, то в настройках для события можно указать периодичность проверки статуса (в секундах). Если этот параметр не задавать, то статус события будет актуализироваться автоматически при каждом вызове «Монитора», после обработки события, либо по требованию пользователя. 
  4. Иногда пользователю недостаточно видеть только статус события — «обработано»/«не обработано», но также требуется проанализировать список необработанных объектов. Алгоритм формирования такого списка может быть задан в этой же функции проверки исполнения. Список создается при каждой актуализации статуса события и всегда доступен пользователю в панели «Монитора». 

    Очевидно, что не для всех событий могут быть заданы алгоритмы проверки исполнения, в этом случае событие будет отражаться в «Мониторе» со статусом «не определено» — просто как напоминание. 

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

Все статьи

Комментарии



Подписка на рассылку
Сортировать
Теги:
Все теги
Выберите интересующий Вас продукт компании
Любой продукт
Сортировать по году:
2015 2016 2017 2018 2019 2020