Автоматизированная система по управлению бизнес-процессом обработки данных клиента коммерческого банка

1.

Автоматизированная система
по управлению бизнеспроцессом обработки данных
клиента коммерческого банка
Подготовил ст. гр. ПИ-1-17 Каргин К.А.

2.

Введение
Пред квалификационную практику я проходил в ЗАО «Банк Азии».
Перед до мной стояла задача разработать систему – «Автоматизированная
система по управлению бизнес-процессом обработки данных клиента
коммерческого банка».
Во время прохождения практики были поставлены следующие
цели и задачи:
Разработка функциональных требований
Проектирование архитектуры системы
Проектирование базы данных и ее реализация
Проектирование основных диаграмм моделирования и поведения
системы

3.

Текущее состояние
Дублирование запросов
Запись данных из внешних источников, происходит вручную
Нет централизованного ведения запросов
Неоправданное использование времени и денежных средств на
обработку данных клиента

4.

Текущее состояние

5.

Текущее состояние

6.

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

7.

Анализ требований
Бизнес требование разработки ПО
Автоматизировать сбор и обработку данных по клиентам
Сократить денежные затраты на сбор информации о клиенте на 40%
Сократить время сбора и обработки данных на 30% от текущих
временных затрат
Интегрировать разрабатываемую АС, во все системы компании
требующие личную информацию клиента
Реализовать веб интерфейс для взаимодействия с системой

8.

Анализ требований
Бизнес цель разработки ПО
Разработка данного ПО, позволит централизованно обрабатывать данные
клиента и использовать единый стандарт передачи данных для систем, использующих
данные клиента.
Целю разработки данного ПО, является автоматизация управления бизнеспроцессом обработки данных клиента, которая позволит уменьшить время сбора и
обработки данных на 40%, уменьшить денежные затраты на сбор информации на 50%.
А также повышение эффективности работы с персональными данными клиента в
пользу коммерческого банка за счет:
Систематизации хранения и учета истории запросов во внешние системы, обеспечения
их надежного хранения, поддержки целостности
Сокращения времени на заполнение шаблонных документов и минимизации ошибок
при их заполнении
Обеспечения возможности получения документа отчетности о совершенном запросе

9.

Входные данные
Паспортные данные
клиента
Согласие клиента на
обработку данных

10.

Пользователи разрабатываемого ПО
Сотрудник
коммерческого банка
(пользователь)
Администратор

11.

Структура системы
Программная структура «АСУ БП ОДК» определяет создание
следующих подсистем:
Подсистема, реализующая основную логику взаимодействия с БД и
внешними системами
Подсистема WEB-портала, реализующая уровень представления и вывода
данных на экран пользователя

12.

Требования к ПО
Подсистема (сервис) АСУ БП ОДК
Функциональные требования
Подсистема (сервис) АСУ БП ОДК должна:
Осуществлять авторизацию в системе с использованием JWT-токена и SSO,
действующего один час
Осуществлять проверку доступа пользователя на совершения запроса
Формировать справку по клиенту
Запрашивать и формировать информацию о клиенте со следующих внешних
систем:
• ГРС
• КИБ
• СФ
• ГАИ
• Госрегистр
Осуществлять проверку наличия и актуальности согласия на сбор данных
Производить загрузку и редактирование согласия на сбор данных

13.

Требования к ПО
Осуществлять отправку кода OTP на телефон/почту запрашиваемого лица для
подтверждения согласия
Формировать отчеты по запросам во внешние системы
Редактировать пользователя системы
Редактировать ролей системы
Осуществлять проверку актуальности данных на момент запроса
Редактировать тарифы по запросам во внешние системы
Формировать отчет и вести учет по платежам за запросы
Редактировать информацию внешних систем (добавление, блокировка)
Формировать ведомость по социальным выплатам

14.

Требования к ПО
Нефункциональные требования
Система должна использовать протокол gRPC для передачи данных
Хранить согласие клиента в формате pdf, на файловом сервере

15.

Требования к ПО
Подсистема WEB-портала
Пользовательские требования
Администратор:
Ввод логина и пароля
Редактирование пользователей системы. Вводятся следующие данные:
Код исполнителя из АБС
Активность исполнителя
Код роли системы
Редактирование ролей системы. Вводятся следующие данные:
Наименование роли
Уровень доступа
Список доступов
Редактирование доступов в системе. Вводятся следующие данные:
Наименование доступа
Идентификатор доступа (уникальный)
Номер модуля

16.

Требования к ПО
Подсистема WEB-портала
Редактирование внешних систем. Вводятся следующие данные:
Наименование системы
Сокращенное наименование(латиница)
Активность системы
Стоимость запроса
Пользователь:
Ввод логина и пароля
Выбор вида отчета
Регистрация(добавление) нового клиента. Вводятся следующие данные:
ИНН
Серия паспорта
Номер паспорта
Номер телефона

17.

Требования к ПО
Прикрепление файла согласия на сбор и обработку данных. Вводятся следующие
данные:
Файл в формате pdf
Получение информации из внешних систем
Ввод OTP кода, для подтверждения согласия
Ввод ключа для поиска клиента
Настройка фильтра для отображения данных
Функциональные требования
Подсистема WEB-портала должна:
Проверять логин и пароль, введенный пользователем
Предоставить возможность выбора отчета:
Персональные данные
Доходы клиента
Кредитная история клиента
Ведомость банка

18.

Требования к ПО
Предоставить возможность добавить клиента
Сохранять/обновлять данные клиента
Читать и сохранять файл согласия на обработку данных в формат base64
Отправлять OTP код на сервис для подтверждения согласия
Формировать и выводить отчеты на печать
Предоставить возможность ввода даты окончания действия разрешения
Предоставить возможность редактировать следующие сущности системы:
Пользователи
Роли
Доступы
Внешние и внутренние системы
Оповестить при успешно выполненном запросе
Фильтровать полученные данные

19.

Требования к ПО
Нефункциональные требования
Web-портал должен иметь следующую структуру страниц:
Главная страница
Страница авторизации
Страница выбора отчета
Страница поиска и редактирования клиента
Страницы отображения для следующих отчетов:
o Персональные данные
o Доходы
o Кредитная история
o Ведомость
Страница редактирования пользователей
Страница редактирования ролей и доступов
Страница редактирования внешних и внутренних систем
Страница отображения истории запросов

20.

Требования к ПО
Веб-дизайн должен быть адаптивный, т.е. обеспечивающий корректное отображение
сайта на различных устройствах, подключённых к интернету и динамически
подстраивающийся под заданные размеры окна браузера.
Дизайн и функционал WEB-портала должны быть рассчитаны на пользователей,
минимально владеющих компьютером и Интернетом.
Сайт должен состоять из взаимосвязанных разделов с четко разделенными функциями.
Пользовательский интерфейс сайта должен обеспечивать наглядное, интуитивно
понятное представление структуры, размещенной на нем информации, быстрый и
логичный переход к разделам и страницам

21.

Концептуальная модель
АСУ БП ОДК
Прикрепление
согласия клиента
Авторизация
<<включить>>
Регистрация
клиента
Выполнить
сохранение
Вывести доступные
отчеты
<<включить>>
Прикрепить
согласие клиента
Выбрать отчет
<<расширить>>
<<включить>>
<<включить>>
Ввести данные
клиента
Вывести
на печать
Сотрудник
Сотрудник
<<включить>>
<<включить>>
<<включить>>
Генерация jwt-токена
Проверка
паспортных данных
<<расширить>>
<<включить>>
Проверить учетные
данные
ГНС
ГНС
Сохранение
в БД
<<расширить>>
Проверить наличие
согласия
Сформировать
отчет
Отправить
код ОТР
СМЭВ "Тундук"
СМЭВ
«ТУНДУК»

22.

Структура базы данных
external_systems
PK
query_types
query_cost
id
ext_query_type
name
name
query_type_id
enabled
ext_sys_id
cost
actuality_days
date_start
enabled
date_end
PK
id
internal_systems
PK
name
enabled
internal_requests
PK
request_permissions
clients
id
PK
PK
id
file_storage
id
PK
permission_docs
PIN
ext_id
abs_id
client_id
date_reg
query_type_id
permission_id
id_series
date_start
doc_type
id_number
date_end
file_id
reg_address
revoked
enabled
id
actual_address
date
cellphone
int_sys_id
phone
user_id
email
PK
id
PK
service_requests
PK
access_groups
users
request_status
PK
user_id
id
date_start
name
date_end
description
access_group
report_passport_inf
o_int
id
fio
date
is_admin
int_sys_id
enabled
report_passport_inf
o_ext
report_salary_info_i
nt
user_id
report_salary_info_
ext
serv _query_type
report_KIB_info_int
request_status
report_KIB_info_ext
salary_info_response
external_requests
PK
passport_info_request
id
ext_request_id
ext_request_id
employer
PIN
employer_inn
id_series
employer_SF_num
id_number
date_start
void_status
date_end
name
salary
date
internal_request_id
user_id
client_id
query_type_id
expiry_date
KIB_contracts_response
surname
request_status
ext_request_id
start_date
real_end_date
KIB_CIP_response
PK
subscriber
id
role_of_client
ext_request_id
status
date
currency
grade
total_value
score
total_local_value
probability_of_defa
ult
interest_value
interest_local_value
trend
monthly_value
monthly_local_valu
e
installment_value
installment_local_v
alue
due_amount_value
due_amount_local_
value
due_interest_value
due_interest_local_
value
number_of_installm
ents
number_of_due_ins
tallments
principal_outstandi
ng_amount
total_past_due_am
ount
contract_type
patronymic
family_status
marital_status
gender
birth_date
issue_date
expiry_date
authority
authority_code
photo_id
reg_address
address_region
address_locality
address_street
address_house
address_building
address_apartment
file extension
date
client_id
int_query_type
id

23.

Диаграмма деятельности
Диаграмма деятельности «Авторизация»

24.

Диаграмма деятельности
Диаграмма деятельности «Регистрация клиента»

25.

Диаграмма деятельности
Диаграмма деятельности «Формирование ведомости по клиенту»

26.

Диаграмма классов

27.

Диаграмма компонентов

28.

Диаграмма размещения

29.

Заключение
Входе прохождения практики были решены следующие задачи
Проведен анализ предметной области
Обоснован функционал разрабатываемой системы
Разработаны требования к ПО
Разработана и реализована архитектура базы данных
Спроектирована концептуальная модель ПО