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

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

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

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

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

Рисунок 1 – Декомпозиция процесса «Открытие дополнительного счета»

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

Рисунок 2 – Инфологическая база данных

В результате была разработана форма открытия дополнительного счета представленная на рисунке 3.

Рисунок 3 - Форма открытия дополнительного счета

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

ВГУЭС

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

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

Под нестабильной политической обстановкой подразумевается ниспадающая на протяжении последнего года угроза введения странами Запада экономических санкций против Российской Федерации. Информация в возможном вводе санкций, направленных на скорое отключение Российской Федерации от международной межбанковской системы передачи информационных сообщений SWIFT [1], была распространены такими российскими интернет-изданиями «банки.рф» и «TheVillage», что посеяло панику среди специалистов финансовой области и заставило руководство центрального банка принять меры к внедрению собственной системы передачи сообщений. Такая система аналогично системе SWIFT, могла бы передавать финансовые, распорядительные и прочие документы в виде файлов, оформленных по единому общепринятому стандарту.

Система передачи электронных сообщений (ЭС) представляет собой свод общегосударственных стандартов и требований по оформлению ЭС, которые оговаривают их содержание и структуру [2]: набор тегов, порядок передачи документов, их особенности и характеристики и пр. Сами же ЭС представляют собой текстовые файлы формата xml, содержащие информацию о каком либо документе (или нескольких документах), текст которых состоит из заголовка, основы и хвостовика. В качестве участников системы чаще всего выступают центр обработки сообщений (ЦОС) Банка РФ и кредитные организации, включенные в список пользователей системы. Задача первых – обеспечить прием, дешифровку, проверку и передачу входящих ЭС между кредитными организациями в соответствии с регламентом унифицированных форматов электронных банковских сообщений (УФЭБС). Задача вторых – обеспечить возможность приема и дешифровки входящих сообщений со стороны ЦОС, а также возможности формирования и отправки исходящих сообщений. Опять же, с соблюдением всех требований по их оформлению.

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

Руководством департамента информационных банковских технологий (ДИБТ) коммерческой организации было принято решение о внедрении программного модуля для автоматизации выполнения данных задач в уже используемую на предприятии автоматизированную банковскую систему (АБС) коммерческой организации [3], предназначенную для автоматизации работы со счетами юридических лиц. Данная система базируется на популярной платформе Oracle 10g и имеет модульную структуру, что дает возможность в дальнейшем расширять и дополнять ее функционал. А значит, процесс создания и внедрения модуля обмена ЭС не потребует масштабной реструктуризации системы и переобучений персонала. Благодаря этим качествам система имеет довольно широкое распространение среди банков России, что дает возможность ускорить и удешевить процесс внедрения нового программного обеспечения (ПО).

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

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

Рисунок 1 – Диаграмма Gant(a): календарный план-график этапов проекта внедрения

В процессе внедрения участвовали начальник и куратор ОСИСБ, программист отдела программного обеспечения информационных банковских систем (ОПОБТ) и помощник специалиста ОСИСБ [4]. Весь процесс состоит из шести этапов:

а) Подготовка ИС к внедрению модуля;

б) Подготовка персонала;

в) Комплектация ИС поставляемыми программными средствами;

г) Проведение предварительных испытаний;

д) Проведение опытной эксплуатации;

е) Проведение приемочных испытаний.

Рассмотрим каждый этап процесса внедрения.

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

Далее в ходе подготовки персонала назначенными сотрудниками были изучены служебная записка и техническое задание на разработку модуля.

После изучения документов на этапе комплектации ИС поставляемыми программными средствами сотрудниками ОПОБТ и ОСИСБ был проведен ряд работ по интеграции модуля в система. Данная процедура потребовала реорганизации базы данных системы. Реорганизация была проведена согласно схеме информационной архитектуры модулей осуществления обмена ЭС (рисунок 2).

Рисунок 2 – Общая схема информационной архитектуры системы

После отладки работы модуля в тестовой версии ИС, начался этап предварительных испытаний, в ходе которого сотрудниками ОСИСБ было произведено так называемое «дымовое» тестирование, а также силами ОПОБТ осуществлялось исправление обнаруженных ошибок. «Дымовое» тестирование направлено на проверку стабильности работы системы [5].

Практически одновременно с этапом предварительных испытаний начался этап опытной эксплуатации, на котором в отделе ОСИСБ был проведен ряд регрессивных и санитарных тестов по данным дерева функций, составленного отделом разработки (рисунок 3).

Рисунок 3 – Дерево функций модуля «Сообщения формата ED5XX»

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

Регрессивные тесты проводились с целью проверки ошибок, выявленных при дымовом тестировании. Санитарное тестирование, ход которого отражен в карте, направлено на тестирование корректности работы функций модуля. Как можно видеть из рисунка №4, большинство функций модуля исправно выполняют свою работу. Исключением является функция формирования исходящих сообщений-запросов. Исходя из данных тестирования, было принято решение отправить модуль передачи ЭС вместе с картой тестирования в отдел ОПОБТ для дальнейших доработок.

Рисунок 4 – Карта тестирования функционала модуля

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

В общем, исходя из проделанной работы по внедрению ПО, можно сказать, что модуль обмена электронными сообщениями формата ED5XX имеет широкие перспективы развития. В ходе дальнейших модернизаций и доработок будет расширяться функционал модуля, а также повышаться стабильность его работы и совместимость в другими модулями АБС коммерческой организации. Также в дальнейшем планируется обеспечить возможность приема и обработки электронных сообщений всех типов, представленных в альбоме УФЭБС, что позволит в дальнейшем создать полноценную альтернативу модулям, работающим с системой SWIFT.