Пояснительная записка - Федоренко АВ 943 группа Хабаовск 2015 (1218829), страница 2
Текст из файла (страница 2)
2.1 Описание исходного бизнес-процесса
Одной из задач, которую выполняет УФР – это выявление и предотвращение как внутренних, так и внешних мошеннических действий. В рамках данной задачи руководством управления был сформирован бизнес-процесс, который благодаря оперативной работе сотрудников всех отделов позволял оперативно выявлять фрод инциденты. Далее подробно показаны все стадии исходного бизнес-процесса.
В начале инициатор (в роли инициатора могут выступать любые участники процесса) по определенным триггерам формирует реестр заявок, подлежащих проверке, и передает его в отдел технологий противодействия мошенничеству при помощи внутренней корпоративной электронной почты. После того как сотрудник ОТПМ получил задание от инициатора ему необходимо выгрузить информацию из хранилища данных и сформировать фрод-кейс в формате Excel книги. Полученную книгу ОТПМ отправляет по электронной почте руководителю отдела расследования фрод инцидентов. Руководитель или ответственное лицо распределяет кейс по сотрудникам ОРФИ и рассылает данные в формате Excel книг каждому сотруднику по электронной почте. Разбиение кейса по сотрудникам выполняется при помощи специальных программ, называемых макросами. Макрос (или макрокоманда) – это программный алгоритм действий, которые записываются пользователем. Каждый кейс имеет определенную структуру, изменение которой может привести к сбою в последующей работе макросов. После того как сотрудник ОРФИ получил кейс в работу, он начинает прозвон клиентов, которые указаны в кейсе. По окончанию проверки сотрудник заносит в файл кейса информацию о заемщике (личная информация, информация о доверенных лицах и т.д.) и выставляет результаты проверки. Как только сотрудники закончили работу над кейсом, они высылают его по электронной почте руководителю ОРФИ. Руководитель выполняет проверку полученной информации о проверке. В случае, когда сотрудник ОРФИ допустил ошибку, руководитель отправляет кейс на доработку. Если при проверке ошибок допущено не было, руководитель отправляет по электронной почте заявки, по которым в результате проверки была выставлена реакция «предположительный фрод инцидент» на ответственного сотрудника отдела регионального контроля. Сотрудник ОРК распределяет заявки согласно территориальной принадлежности и рассылает их в формате Excel книг на сотрудников службы экономической защиты. Сотрудники СЭЗ производят проверку ссуд с предположительным мошенничеством и производят заключение. Результат работы отправляется обратно на руководителя ОРФИ и ответственного сотрудника ОРК. На финальном этапе проверки кейса все данные суммируются и заносятся в Excel книгу. Полученный файл выкладывается под уникальным именем в общую папку на сервере. Для наглядного представления описанный выше процесс показан на рисунке 1.
Рисунок 1 – Исходная схема бизнес-процесса
После рассмотрения исходного бизнес-процесса необходимо провести его анализ.
2.2 Анализ бизнес-процесса
Как мы видим данный процесс имеет ряд существенных недостатков. Во-первых, все взаимодействия между участниками осуществляются исключительно при помощи электронной почты. Такой вид связи не является достаточно надежным, более того, есть риск, что сообщение не дошло, и тогда процесс может прерваться на одном из этапов. Так же данный вид связи наносит ограничение на пересылаемые данные (размер вложения в программе MS Outlook не должен превышать 8 мегабайт). К тому же, при использовании электронной почты в процессе проверки ссуд на наличие фрод инцидентов отсутствует общая структура информации о том на какой стадии в данный момент находится проверка, какое время требуется сотрудникам на том или ином этапе и так далее.
Во-вторых, информация о проведенных проверках хранится на общем диске в формате Excel книг. Данный вид хранения информации не только не надежен, но и не удобен при составлении ежемесячной или еженедельной отчетности о результатах проверки. Так же для поиска необходимого проверенного кейса уходит достаточно много времени.
Одним из главных недостатков является тот факт, что при данной организации участники процесса должны хранить на локальных дисках информацию о каждом кейсе отдельно друг от друга. Данная организация хранения и обработки информации значительно замедляет работу сотрудника, соответственно замедляет весь процесс проверки.
Таким образом проведя анализ бизнес-процесса был выявлен ряд существенных недостатков, а также был разработан план по выполнению автоматизации работы [6].
2.3 План автоматизации бизнес-процесса
Прежде всего необходимо обеспечить централизованность хранения информации. Было предложено хранить всю информацию в базе данных. Данный вид хранения информации имеет ряд существенных преимуществ таких как: высокая степень надежности, структурированность данных, простота доступа и т.д. Такой подход к хранению информации решает проблему с избыточностью локальных данных, а также позволяет гораздо быстрее получать участникам процесса необходимые данные [7].
Так же была разработана схема, согласно которой каждый участник процесса имел свою собственную рабочую форму. Суть идеи заключается в том, чтобы связать всех участников процесса при помощи программного клиентского обеспечения в рамках которого пользователь выполняет тот участок процесса, за который он несет ответственность. Все рабочие формы связанны между собой при помощи базы данных. Таким образом исключается необходимость пересылать информацию между участниками процесса по электронной почте, так как данные, которые поступили в работу будут подгружаться в рабочую форму автоматически.
После введения выше указанных предложений можно сформировать новую схему бизнес-процесса. Данная схема показана на рисунке 2.
Рисунок 2 – Новая схема бизнес-процесса
Согласно данной схеме инициатор процесса заполняет заявку на проведение проверки при помощи специального программного обеспечения. Информация о инициализации регистрируется в базе данных, заносятся данные о времени инициализации, пользователе, причинах и направлении проверки. После регистрации сотруднику ОТПМ в специальную форму приходит уведомление о необходимости предоставления информации для ОРФИ из хранилища данных. Когда сотрудник ОТПМ выгрузил данные из ХД он при помощи рабочей формы отправляет информацию о кейсе на проверку в базу данных. Параллельно с этим происходит автоматическое уведомление руководителя ОРФИ о поступлении кейса в работу. Руководитель ОРФИ распределяет заявки по сотрудникам и заносит информацию в базу данных. Каждый сотрудник ОРФИ имеет свою рабочую форму, в которую из базы подгружаются те заявки, которые находятся у него в работе. После отработки кейса руководителю ОРФИ приходит уведомление о готовности, и, если ошибок нет, он выставляет статус кейса в «отправлено в СЭЗ». Также, как и у ОРФИ, сотрудники СЭЗ имеют свою рабочую форму, в которую заносится информация из базы только о тех заявках, по которым выставлен статус «предположительный фрод инцидент». Как только сотрудниками СЭЗ были проверены все заявки из кейса, то статус проверки становится «Выполнено» и она заносится в общий реестр, хранящийся в базе.
Таким образом при автоматизации бизнес-процесса необходимо создать полностью структурированную базу данных, а также комплекс клиентского программного обеспечения, что позволит значительно упростить процесс проверки фрод инцидентов, тем самым повысит производительность управления фрод рисков [6].
3 ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
По мере развития экономики возрастает объем данных, которые взаимосвязаны между собой. Эти данные необходимы для решения коммерческих и административных задач. Взаимосвязанные данные называют информационной системой. Такая система в первую очередь призвана облегчить труд человека, но для этого она должна как можно лучше соответствовать очень сложной модели реального мира [8].
Ядром информационной системы являются хранимые в ней данные. На любом предприятии данные различных отделов, как правило, пересекаются, то есть используются в нескольких подразделениях или вообще являются общими. Например, для целей управления часто нужна информация по всему предприятию. Хранящиеся в информационной системе данные должны быть легко доступны в том виде, в каком они нужны для конкретной производственной деятельности предприятия. При этом не имеет существенного значения способ хранения данных [9]. Сегодня на предприятии мы можем встретить систему обработки данных традиционного типа, в которой служащий вручную помещает данные в скоросшиватель, и рядом с ней – современную систему с применением самой быстродействующей ЭВМ, сложнейшего оборудования и программного обеспечения. Несмотря на поразительную несхожесть, обе эти системы обязаны предоставлять достоверную информацию в определенное время, определенному лицу, в определенном месте и с ограниченными затратами [10].
3.1 Особенности проектирования баз данных
Основной формой организации хранения данных в информационных системах являются базы данных. При проектировании системы обработки данных именно данные играют важнейшую роль.
Система автоматизированной обработки данных основывается на использовании определенной модели данных или информационной модели. Модель данных отражает взаимосвязи между объектами [10].
Процесс создания информационной модели начинается с определения концептуальных требований ряда пользователей. Концептуальные требования могут определяться и для некоторых задач (приложений), которые в ближайшее время реализовывать не планируется. Это может несколько повысить трудоемкость работы, однако поможет наиболее полно учесть все нюансы функциональности, требуемой для разрабатываемой системы, и снизит вероятность ее переделки в дальнейшем. Требования отдельных пользователей интегрируются в едином «обобщенном представлении». Последнее называют концептуальной моделью [11].
Концептуальная модель представляет объекты и их взаимосвязи без указания способов их физического хранения.
Таким образом, концептуальная модель является, по существу, моделью предметной области. При проектировании концептуальной модели все усилия разработчика должны быть направлены в основном на структуризацию данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности обработки. Проектирование концептуальной модели основано на анализе решаемых на этом предприятии задач по обработке данных. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных [12].
Концептуальная модель транслируется затем в модель данных, совместимую с выбранной СУБД. Возможно, что отраженные в концептуальной модели взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения концептуальной модели. Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью[12].
Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среде хранения.
Логическая модель данных может быть реляционной, иерархической или сетевой. Пользователям выделяются подмножества этой логической модели, называемые внешними моделями, отражающие их представления о предметной области [13]. Внешняя модель соответствует представлениям, которые пользователи получают на основе логической модели. В то время как концептуальные требования отражают представления, которые пользователи первоначально желали иметь и которые легли в основу разработки концептуальной модели. Логическая модель отображается в физическую память, такую, как диск, лента или какой-либо другой носитель информации.
Физическая модель, определяющая размещение данных, методы доступа и технику индексирования, называется внутренней моделью системы.
Внешние модели никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Это положение отражает первый уровень независимости данных. С другой стороны, если концептуальная модель способна учитывать расширение требований к системе в будущем, то вносимые в нее изменения не должны оказывать влияния на существующие внешние модели. Это – второй уровень независимости данных. Построение логической модели обусловлено требованиями используемой СУБД [14].
Все актуальные требования предметной области и адекватные им «скрытые» требования на стадии проектирования должны найти свое отражение в концептуальной модели. Конечно, нельзя предусмотреть все возможные варианты использования и изменения базы данных. Но в большинстве предметных областей такие основные данные, как объекты и их взаимосвязи, относительно стабильны. Меняются только информационные требования, то есть способы использования данных для получения информации.