Министерство науки и высшего образования Российской Федерации
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«Сибирский государственный автомобильно-дорожный университет
(СибАДИ)»
Институт магистратуры и аспирантуры
Направление 09.04.01 Информатика и вычислительная техника
Магистерская программа «Архитектура предприятия и
информационными процессами»
Кафедра «Прикладная информатика»
управление
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к магистерской диссертации
Обозначение магистерской диссертации МД-02068982-09.04.01-01-21
Тема магистерской диссертации: «Автоматизация управления процессом
взаимодействия при организации возврата просроченных задолженностей на
стадиях soft-, hard- и legal-collection»
Студентка Батурина Анна Сергеевна
Магистерская диссертация допущена к защите в ГЭК
Заведующий кафедрой, канд. экон. наук, доц.
__________ Л.И. Остринская
«___»___________2020 г.
Руководитель магистерской программы
декан фак. ИСУ, зав. каф. ПИ,
канд. экон. наук, доц.
__________Л.И. Остринская
Руководитель магистерской диссертации
декан фак. ИСУ, зав. каф. ПИ,
канд. экон. наук, доц.
__________ Л.И. Остринская
Нормоконтроль
доц. каф. ПИ, канд. пед. наук
____________ С.Ю. Пестова
Омск 2021
Министерство науки и высшего образования Российской Федерации
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«Сибирский государственный автомобильно-дорожный университет
(СибАДИ)»
Кафедра «Прикладная информатика»
УТВЕРЖДАЮ
Зав. кафедрой
«Прикладная информатика»
_____________ Л.И. Остринская
«__» _________ 2020 г
Задание
к магистерской диссертации студентки Батуриной Анна Сергеевны
1 Тема МД: «Автоматизация управления процессом взаимодействия при
организации возврата просроченных задолженностей на стадиях soft-, hard- и
legal-collection».
2 Исходные данные к МД: нормативы и законодательные акты Российской
Федерации, положения, интернет-ресурсы.
3 Содержание пояснительной записки:
1) Введение
2) Анализ и выбор проектных решений для разработки целевой архитектуры
проекта
3) Проектирование архитектуры программного комплекса
4) Разработка и тестирование архитектуры программного комплекса
5) Заключение
6) Список использованной литературы
4 Перечень демонстрационного материала для сопровождения докладов в ГЭК
1) Презентация
2) Раздаточный материал к научному докладу
5 Назначенный кафедрой рецензент МД: директор ООО «Компания развития
доступных систем» П.Л. Ильюшевич
Задание выдано «___» ____________ 2020 г.
Руководитель МД ______________________ / Л.И. Остринская
(подпись)
Задание к исполнению приняла «___» ____________ 2020 г.
Студентка _________________ / А.С. Батурина
(подпись)
2
Аннотация
Пояснительная записка 70 с., 39 рис., 8 табл., 56 источников.
ПРОГРАММНЫЙ
КОМПЛЕКС,
АВТОМАТИЗАЦИЯ,
КОЛЛЕКТОРСКАЯ
ДЕЯТЕЛЬНОСТЬ,
ОБЛАЧНЫЕ
ТЕХНОЛОГИИ,
АРХИТЕКТУРА
ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ,
РАЗРАБОТКА,
ТЕСТИРОВАНИЕ.
Результаты магистерской диссертации представлены в пояснительной
записке. В ходе работы исследованы потенциальные объекты автоматизации,
которые в рамках своей деятельности взаимодействуют с должниками по
вопросам возврата просроченных задолженностей. В диссертации приведены
результаты: анализа предметной области, этапа проектирования, а также
разработки и тестирования возможностей программного решения.
Степень внедрения – программное решение передано на опытное
тестирование нескольким объектам автоматизации, основные результаты
исследования предметной области доложены и опубликованы в сборниках
научных трудов на: 3 международной научно-практической конференции
студентов, аспирантов и молодых ученых «Архитектурно-строительный и
дорожно-транспортный комплексы: проблемы, перспективы, инновации» в
ФГБОУ ВО «СибАДИ» (29 – 30 ноября 2018 года); 5 международной научнопрактической конференции «Архитектурно-строительный и дорожнотранспортный комплексы: проблемы, перспективы, инновации» в ФГБОУ ВО
«СибАДИ» (3 – 4 декабря 2020 года).
SOFTWARE PACKAGE, AUTOMATION, COLLECTION ACTIVITIES,
CLOUD TECHNOLOGIES, SOFTWARE ARCHITECTURE, DEVELOPMENT,
TESTING.
The results of the master's thesis are presented in the explanatory note. In the
course of the work, potential automation objects that interact with debtors on the return
of overdue debts within the framework of their activities are investigated. The
dissertation presents the results of: the analysis of the subject area, the design stage, as
well as the development and testing of the capabilities of the software solution.
Degree of implementation – the software solution was transferred for pilot
testing to several automation objects, the main results of the research of the subject
area were reported and published in the collections of scientific papers at: 3
international scientific and practical conference of students, postgraduates and young
scientists "Architectural, construction and road transport complexes: problems,
prospects, innovations" in SibADI» (29-30 november 2018); 5 International scientific
and practical conference «Architectural, Construction and Road transport Complexes:
Problems, Prospects, Innovations» in SibADI (3-4 December 2020).
3
Список условных обозначений и сокращений
БД
БЕ
ГК
ДС
ЕФРСБ
ИО
ИС
ИТ
КД
КИ
КоАП РФ
МФУ
НК
ПК
ПО
ПСК
РФ
СУБД
ФЗ
ФЛ
ФССП
ЦБ
ЮЛ
ЯП
AS-IS
BPMN
EPC
IDEF0
MS
TO-BE
UML
База данных
Бизнес-единица
Гражданский кодекс России
Денежные средства
Единый федеральный реестр сведений о банкротстве
Информационное обеспечение
Информационная система
Информационные технологии
Кредитный договор
Конфиденциальная информация
Кодекс административной ответственности России
Многофункциональное устройство
Налоговый кодекс России
Программный комплекс
Программное обеспечение
Полная стоимость кредита
Российская Федерация
Система управления базами данных
Федеральный закон
Физическое лицо
Федеральная служба судебных приставов России
Ценные бумаги
Юридическое лицо
Язык программирования
Модель представления данных на основе существующих
процессов «как есть»
Методология моделирования бизнес-процессов «Business
Process Model and Notation»
Методология событийной цепочки процессов «Event-Driven
Process Chain»
Методология графического моделирования функциональных
моделей «Integration Definition for Function Modeling»
Microsoft Office
Модель представления данных на основе существующих
процессов «как должно быть»
Унифицированный язык моделирования «Unified Modeling
Language»
4
Содержание
Введение ....................................................................................................................... 7
1 АНАЛИЗ ОБЪЕКТА АВТОМАТИЗАЦИИ И ПРЕДМЕТНОЙ ОБЛАСТИ ...... 9
1.1 Инфраструктура объектов автоматизации: типовые организационные
структуры ..................................................................................................................... 9
1.2 Теоретические аспекты предметной области ............................................... 12
1.3 Терминология предметной области .............................................................. 13
1.4 Нормативно-правовая база предметной области ......................................... 14
1.5 Математические модели предметной области ............................................. 16
1.6 Модели предметной области AS-IS .............................................................. 17
1.6.1 Техническая и программная модели ...................................................... 17
1.6.2 Концептуальная модель........................................................................... 18
1.6.3 Модель бизнес-процесса ......................................................................... 19
1.7 Анализ проблем предметной области ........................................................... 21
2 АНАЛИЗ И ВЫБОР ПРОЕКТНЫХ РЕШЕНИЙ ДЛЯ РАЗРАБОТКИ
ЦЕЛЕВОЙ АРХИТЕКТУРЫ ПРОЕКТА ................................................................ 24
2.1 Анализ функциональных возможностей аналогов программного
комплекса ................................................................................................................... 24
2.2 Анализ и обоснование технологий и платформ проектирования
архитектуры программного комплекса................................................................... 25
2.3 Обоснование выбора технологий и платформ для реализации архитектуры
программного комплекса.......................................................................................... 25
2.4 Обоснование целевой архитектуры программного комплекса .................. 27
2.4.1 Архитектура данных ................................................................................ 27
2.4.2 Архитектура приложений ....................................................................... 28
2.5 Механизмы защиты информации в программном комплексе ................... 31
3 ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ ПРОГРАММНОГО КОМПЛЕКСА . 34
3.1 Модели предметной области TO-BE............................................................. 34
3.1.1 Техническая и программная модели ...................................................... 34
3.1.2 Концептуальная модель........................................................................... 34
3.1.3 Модель бизнес-процесса ......................................................................... 36
3.1.4 Модель вариантов использования .......................................................... 37
3.1.5 Модели состояний .................................................................................... 40
5
3.1.6 Модель компонентов ............................................................................... 43
3.2 Проектирование архитектуры базы данных ................................................. 44
3.3 Проектирование интерфейсной части........................................................... 44
3.4 Информационное обеспечение задачи .......................................................... 50
4 РАЗРАБОТКА И ТЕСТИРОВАНИЕ АРХИТЕКТУРЫ ПРОГРАММНОГО
КОМПЛЕКСА............................................................................................................ 52
4.1 Разработка архитектуры программного комплекса..................................... 52
4.2 Разработка
пользовательской
документации
к
программному
комплексу ................................................................................................................... 53
4.3 Тестирование
функциональных
возможностей
программного
комплекса ................................................................................................................... 54
Заключение ................................................................................................................ 63
Библиографический список ..................................................................................... 65
Приложение А Техническая и программная модели предметной области
AS-IS ........................................................................................................................... 71
Приложение Б Описание бизнес-процесса «Взаимодействие с должником в
рамках возврата просроченных задолженностей» AS-IS...................................... 73
Приложение В Анализ функциональных особенностей информационных систем
предметной области .................................................................................................. 76
Приложение Г Техническая и программная модели предметной области
TO-BE ......................................................................................................................... 79
Приложение Д Описание бизнес-процесса «Взаимодействие с должником в
рамках возврата просроченных задолженностей» TO-BE .................................... 80
Приложение Е
Архитектура баз данных программного
комплекса
«RU-Collector» ........................................................................................................... 84
Приложение Ж
Прототипы
интерфейсов
программного
комплекса
«RU-Collector» ........................................................................................................... 85
Приложение И Листинг кода программного комплекса «RU-Collector» .......... 103
Приложение К Пользовательская документация программного комплекса
«RU-Collector» ......................................................................................................... 113
6
Введение
В настоящее время сфера кредитования физических и юридических лиц на
территории Российской Федерации занимает одну из лидирующих позиций в
финансовом секторе экономики страны.
Банки и микрофинансовые организации предлагают населению различные
виды кредитов с целью получения прибыли от такого роди актива. Параллельно
с популяризацией кредитования активно развивается сфера работы с
просроченными активами, вовремя неуплаченными гражданами. Одним из
главных участников сферы возврата задолженностей являются коллекторские
агентства.
В связи с ростом доли просроченных кредитных активов у граждан
Российской Федерации возрастает потребность в разрезе кредитных и
коллекторских
объектов
комплексной
автоматизации
всех
процессов
взаимодействия с должниками, которая обеспечит контроль соблюдения
законодательной базе, а также может являться доказательной базой при
судопроизводстве и исполнительном производстве.
Актуальность данной магистерской диссертации состоит в необходимости
соблюдать ряд законодательных ограничений при работе с должниками в разрезе
возвратов просроченных задолженностей, а также обеспечению комплексной
автоматизации конечных пользователей – сотрудников и руководителей всех
стадий взыскания.
Объектами исследования являются коллекторские агентства, различные
микрофинансовые организации и банки, которые ведут свою деятельность на
территории Российской Федерации.
Предметом исследования является процесс управления взаимодействием
при организации возврата просроченной задолженности на стадиях soft-, hard- и
legal-collection.
7
Целью работы является проектирование и разработка архитектуры
программного
комплекса
«RU-Collector»,
который
будет
обеспечивать
комплексную автоматизацию предметной области.
Перед началом выполнения данной магистерской диссертации были
поставлены следующие задачи:
1) Выполнить анализ предметной области и объектов автоматизации.
2) Провести анализ и выбор проектных решений для проектирования и
реализации программного решения.
3) Выполнить проектирование архитектуры программного решения.
4) Разработать программный комплекс «RU-Collector» и документацию
для конечных пользователей.
5) Провести тестирование реализованных функциональных возможностей
программного комплекса «RU-Collector».
8
1 АНАЛИЗ
ОБЛАСТИ
ОБЪЕКТА
1.1 Инфраструктура
АВТОМАТИЗАЦИИ
объектов
И
ПРЕДМЕТНОЙ
автоматизации:
типовые
организационные структуры
В качестве объектов автоматизации предметной области можно выделить
три направления бизнеса финансового сектора РФ:
1) Коллекторские агентства – компании, специализирующиеся на сборе и
возврате долговых обязательств ЮЛ и ФЛ перед кредиторами в рамках
договоров уступки прав требования (цессии) или агентским договоров [20].
2) Организации микрозаймов:
– Микрофинансовые организации (МФО) – лицо, которое осуществляет
микрофинансовую
деятельность
и
сведения
о
котором
внесены
в
государственный реестр микрофинансовых организаций [6].
– Микрокредитные организации (МКК) – вид МФО, осуществляющей
микрофинансовую деятельность с учетом установленных ограничений в разрезе
привлечения ДС физических лиц [6].
– Микрофинансовые компании (МФК) – вид МФО, осуществляющей
микрофинансовую деятельность с большей возможностью в отношении выдачи
займов и привлечения ДС [6].
3) Банки – кредитная организация, которая имеет исключительное право
осуществлять в совокупности различные операции с ДС и ЦБ [4].
Каждый
бизнес-объект
способен
выстроить
собственную
организационную структуру исходя из регламентов, масштабов и видения
развития собственного бизнеса.
На рисунках 1-3 рассмотрены типовые инфраструктуры объектов
автоматизации [26, 36].
9
Рисунок 1 – Типовая организационная структура коллекторского агентства
Рисунок 2 – Типовая организационная структура банка
10
Рисунок 3 – Типовая организационная структура организации микрозаймов
Рассматривая обобщенную организационную структуру объектов, можно
выделить базовые не профильные бизнес-единицы следующего характера:
административные (директорат и заместители), управленческие (управление
персоналом, оперативное управление и т.д.), финансово-учетные (бухгалтерия,
планово-экономический отдел, отдел по работе с контрагентами, канцелярия и
т.д.), информационные (ит-департаменты, вычислительные центры и т.д.), а
также вспомогательные [41, 42].
В качестве основных профильных отделов обозначены структурные
подразделения по взаимодействию с должниками по вопросам возврата
просроченной задолженности (отделы коллекторского направления или отделы
взыскания).
11
1.2 Теоретические аспекты предметной области
Коллекторской деятельностью является осуществляемая от своего имени
либо от имени кредитора систематическая деятельность, направленная на
взаимодействие
с
должником
по
вопросам
добровольного
погашения
просроченной задолженности в сторону кредитующей организации либо на
принудительное взыскание задолженности должника, а также деятельность по
приобретению денежных требований к должникам коллекторским агентством с
целью их самостоятельного предъявления.
В роли должника может быть как юридическое, так и физическое лицо,
взявшее на добровольной основе и определенных условиях (период, процентная
ставка, условия досрочного погашения или условия просрочки возврата и т.д.)
ДС и обязующееся вернуть их в срок.
Организация деятельности по возврату просроченной задолженности
осуществляется в рамках трех стадий, представленных в таблице 1 [13, 40].
Таблица 1 – Стадии взыскания просроченных задолженностей
Стадия взыскания и
период взаимодействия
SOFT-Collection
(1-30 дней, редко до 60
дней)
HARD-Collection
(30-90 дней)
LEGAL-Collection
(6-12 месяцев)
Деятельность, совершаемая в рамках стадии взыскания
Сбор информации о должнике и его финансовом состоянии,
дистанционное общение с должником посредством телефонных
звонков, sms- и email-оповещений, почтовых писем.
Взаимодействие с должником на данной стадии характеризуется
направлением пакета претензионных документов,
консультирование о возможных негативных последствия
неоплаты задолженности, сохранение клиента для кредитной
компании при возможности возвращения его в график платежей.
Возврат долгов без судебного процесса, продолжение
внесудебных мероприятий посредством личного взаимодействия
с должником, включая встречи по месту фактического
нахождения должника или в офисе агентства. На данной стадии
сотрудники кредитной организации разъясняют негативные
последствия дальнейшего уклонения от возврата долга,
порождают мотивацию должника к возврату ДС, предоставляют
варианты реструктуризации долга.
Передача дела в суд в рамках искового или приказного
судопроизводства, исполнительное производство,
взаимодействие с судебными приставами.
В рамках данной предметной области также фигурируют задолженности
следующих видов:
12
– Простая – общая сумма задолженности должника перед кредитной
организацией, полученная в рамках заключения КД.
– Процентная
–
задолженность,
рассчитываемая
исходя
из
установленного на КД процента, значения ПСК или других установленных
кредитором значений, например: процентная задолженность, просроченная
процентная задолженность.
– Тарифная – задолженность фиксированного типа или рассчитываемая
исходя из процентного соотношения к определенной базовой задолженности,
например: штрафы, пени, неустойки, госпошлины, комиссии за операции и
т.д [39].
Каждый вид задолженности может устанавливаться определенной суммой
или рассчитываться по формуле, приведенной в пункте 1.5.
1.3 Терминология предметной области
Для понимания предметной области рассмотрим основные термины и
определения. Часть из них определены в законодательстве РФ, а другие –
компанией-разработчиком ООО «КРДС». Терминология предметной области
представлена в таблице 2 [17].
Таблица 2 – Перечень терминов и определений предметной области
Термин
Программный
комплекс
Программный
сервис
Программное
решение
Бизнес-процесс
Реализация
Должник
Задолженность
Требование
Портфель
требований
Определение термина
Совокупность программных сервисов и решений, позволяющая
частично или комплексно автоматизировать бизнес.
Автоматизация взаимодействия с внешними информационными
системами в части отправки и получения данных любых форматов.
Автоматизированная последовательность действий, которые
позволяют выполнить завершенный подпроцесс в рамках процесса.
Совокупность взаимосвязанных последовательных действий
пользователей, направленных на получение конечного результата.
Автоматизированный вариант исполнения одного варианта действия
бизнес-процесса из всех возможных.
Юридическое или физическое лицо, которое имеет обязательство
перед кредитором.
Долговое обязательство заемщика перед финансовой организацией в
денежном выражении.
Обязательство должника перед кредитором об уплате определенной
денежной суммы.
Группа требований, характеризующаяся однородными параметрами,
определенными стороной кредитования.
13
Продолжение таблицы 2
Термин
Набор
требований
Реквизит
Реквизитный
состав
требования
Статус
требования
Стратегия
взыскания
Мероприятие
Статус
мероприятия
Определение термина
Массив требований, отобранных пользователем по заданным
определенным параметрам и относящихся к различным портфелям
требований.
Обязательный или необязательный элемент, характеризующий
системную сущность (требование) в различных аспектах.
Совокупность различного рода данных (реквизитов),
характеризующих системную сущность.
Состояние, отображающее возможность применения к системной
сущности (требованию) группы функциональных возможностей.
Последовательность взаимодействий с должником в рамках возврата
его просроченной задолженности кредитору, выстроенная по
определенной логике.
Узаконенный в РФ вид взаимодействия с должником по вопросам
возврата просроченной задолженности кредитору.
Состояние, отображающее возможность применения к системной
сущности (мероприятию) группы функциональных возможностей.
Приведенные выше термины используются участниками обозначенной в
магистерской
диссертации
предметной
области,
а
также
в описании
инструментов автоматизации, разработанных компанией ООО «КРДС».
1.4 Нормативно-правовая база предметной области
Деятельность по взаимодействию с должниками по вопросам возврата
просроченных
задолженностей
регламентируется
следующими
законодательными актами:
1) Федеральный закон № 230-ФЗ от 03.07.2016 года «О защите прав и
законных интересов физических лиц при осуществлении деятельности по
возврату просроченной задолженности и о внесении изменений в Федеральный
закон «О микрофинансовой деятельности и микрофинансовых организациях»:
регулирует права и законные интересы всех сторон, устанавливает правовые
основы деятельности по возврату просроченной задолженности ФЛ, возникшей
из денежных обязательств [5].
2) ГК РФ, статья 319 «Очередность погашения требований по денежному
обязательству». Статья разъясняет приоритетность погашения задолженностей
14
при
внесении
должником
платежей,
покрывающих
несколько
видов
задолженностей [1].
3) КоАП РФ, статья 14.57 «Нарушение требований законодательства о
защите прав и законных интересов физических лиц при осуществлении
деятельности по возврату просроченной задолженности»: повествует об
административных мерах, применяемых к ЮЛ в случае нарушений [2].
4) Приказ
ФССП
РФ
№
551
от
30.12.2019
«Об
утверждении
Административного регламента Федеральной службы судебных приставов по
осуществлению
федерального
государственного
контроля
(надзора)
за
деятельностью юридических лиц, осуществляющих деятельность по возврату
просроченной задолженности в качестве основного вида деятельности,
включенных
в
государственный
реестр»:
определяет
сроки
и
последовательность административных процедур (действий) при осуществлении
надзора за коллекторской деятельностью [7].
5) Приказ ФССП РФ № 825 от 28.12.2016 «Об утверждении требований к
оборудованию и программному обеспечению юридического лица, включенного
в государственный реестр юридических лиц, осуществляющих деятельность по
возврату
просроченной
задолженности
в
качестве
основного
вида
деятельности». Данный регламент определяет требования к программному
обеспечению,
автоматизирующему
деятельность
по
взаимодействию
с
должниками по вопросам возврата задолженностей [8].
6) Внутренние регламенты организаций по взаимодействию с должниками
в рамках возврата просроченных задолженностей: правила взаимодействия с
должниками на всех стадиях взыскания задолженностей и алгоритмы
выстраивания стратегий взаимодействия, а также шаблоны, используемые в
различных методах взаимодействия.
7) Уставы организаций.
15
1.5 Математические модели предметной области
Исходя из описанных в пункте 1.2 видов задолженностей, в ПК реализован
функционал по учету задолженностей (S) по следующей формуле:
𝑆=
𝑋 ×𝑌 ×(
𝑖
)
100
𝑍
,
(1)
где X – величина ссудной задолженности;
Y – количество дней для расчета задолженности;
i – процентная ставка;
Z – количество дней в периоде расчета.
Данная формула предназначена для расчета процентной и тарифной
задолженностей.
На стадии судебного взаимодействия исполняется расчет величин:
– Госпошлина по исковому заявлению (A):
𝐴 =𝑖×𝐵+𝑄,
(2)
i – процентная ставка, установленная исходя из ограничений по величине
цены иска в статье 333.19 НК РФ;
B – величина в денежном выражении, являющаяся базовой для процентной
ставки (i) и зависящая от цены иска;
Q – фиксированная величина в денежном эквиваленте [3].
– Ценой иска является сумма остатков по всем видам задолженности в
разрезе одного требования на дату формирования искового заявления.
Зависимость i (процентной ставки) от величины B (цены иска)
представлена в таблице 3.
Таблица 3 – Ограничения по величине цены иска для расчета госпошлины
по исковому заявлению
Формула
ограничений
цены иска
Процентная
ставка
(i)
0-20.000р.
4%
20.001-100.000р.
3%
Базовая величина
(B)
От суммы, равной
цене иска
От суммы,
превышающей
20.000р.
16
Фиксированная
величина
(Q)
0 р.
Дополнительное
ограничение по
величине
госпошлины (А)
Не менее 400р.
800 р.
-
Продолжение таблицы 3
Формула
ограничений
цены иска
Процентная
ставка
(i)
100.001200.000р.
2%
200.0011.000.000р.
1%
Более
1.000.000,00р.
0,5 %
Базовая величина
(B)
От суммы,
превышающей
100.000р.
От суммы,
превышающей
200.000р.
От суммы,
превышающей
1.000.000р.
Фиксированная
величина
(Q)
Дополнительное
ограничение по
величине
госпошлины (А)
3.200р.
-
5.200 р.
-
13.200 р.
Не более 60.000р.
– Госпошлина по судебному приказу:
𝐶=
𝐴
2
=
𝑖×𝐵+𝑄
2
,
(3)
где C – величина госпошлины по судебному приказу;
A – величина госпошлины по исковому заявлению [3].
1.6 Модели предметной области AS-IS
1.6.1 Техническая и программная модели
Техническая модель предметной области демонстрирует наиболее общий
состав технических средств, используемый на объектах автоматизации. Она
включает в себя компьютеры, периферийные и телекоммуникационные
устройства, а также серверную технику (наличие серверной техники
наблюдается у распределенных объектов автоматизации со сложной ИТинфраструктурой). Техническая модель предметной области представлена в
таблице А.1 приложения А и отражает обобщенную структуру технических
устройств на объектах автоматизации обозначенной предметной области.
Программная модель предметной области AS-IS, представленная в
таблице А.2 приложения А, отображает обобщенную структуру базового и
прикладного
ПО,
установленного
на
рабочих
компьютерах
пользователей в исследуемых объектах автоматизации.
17
конечных
Программная модель каждого объекта автоматизации включает в себя
определенный перечень программного обеспечения исходя из регламентов
построения их ИТ-инфраструктуры.
В таблице 3 приложения В представлен обобщенный перечень
популярного базового и прикладного программного обеспечения на объектах
автоматизации.
1.6.2 Концептуальная модель
Концептуальная модель выполнена в нотации IDEF0 и отражает
смысловую структуру предметной области. На рисунке 4 представлена
концептуальная модель предметной области данной магистерской диссертации.
Блок управления отражает две категории конечных пользователей:
руководители и исполнители, которые могут быть отнесены к обобщенному
отделу или же расформированы по отделам на основе стадий взаимодействия.
Блок входной информации содержит 5 ветвей: сведения по должникам
(информационный вид), кредитные договора (материальный вид), сведения по
платежам (информационный вид), суммы ДС, выданных в кредит (денежный
вид), данные о выполненных взаимодействиях с должниками (документальный
вид).
Блок выходной информации содержит 4 ветви: закрытые кредитные
договора (информационный вид), дело по требованию, переданное в бумажный
или электронный архив (материальный вид), прибыль от погашенных
задолженностей (денежный вид), отчетные формы по результатам деятельности
(документальный вид).
Блок нормативно-правовой базы содержит все ранее описанные
регламенты в пункте 1.4.
18
Рисунок 4 – Концептуальная модель предметной области AS-IS
Модель демонстрирует верхний уровень процессов предметной области.
1.6.3 Модель бизнес-процесса
В результате анализа предметной области был построен обобщенный
бизнес-процесс
AS-IS,
отражающий
основную
суть
взаимодействия
с
должниками по вопросам возврата просроченной задолженности. В качестве
исполнителей обозначены – руководитель и специалист коллекторского
направления, заемщик, а в качестве электронных документов – план задач и план
задач (исправленный).
Графическое представление бизнес-процесса AS-IS представлено на
рисунке 5, а его описание – в таблице Б.1 приложения Б.
19
Рисунок 5 – Бизнес-процесс «Взаимодействие с должником в рамках возврата
просроченных задолженностей» AS-IS
20
1.7 Анализ проблем предметной области
Перечень «узких мест» предметной области, отраженных в бизнеспроцессе AS-IS на рисунке 5, представлено в таблице 4. Каждое обозначенное
«узкое место» имеет собственные потенциальные риски и распределение по
бизнес-ролям. Часть «узких мест» имеет схожие потенциальные риски.
Графическая интерпретация «узких мест» и их потенциальных рисков
представлена в виде диаграммы Исикавы на рисунке 6. Совокупность всех
проблем
предметной
области
порождает
главенствующую
проблему,
обозначенную на диаграмме, – отсутствие комплексной автоматизации
процессов возврата просроченных задолженностей.
Таблица 4 – Перечень «узких мест» предметной области
«Узкие места»
Отсутствие
комплексной
автоматизации
деятельности
руководителя (И-1)
Потенциальные риски
– Длительность и рутинность исполнения
этапа работ.
– Низкий уровень актуальности данных по
промежуточным результатам работы
специалистов: устаревшие данные о
должнике, его задолженности или о стадии
взаимодействия с ним.
– Избыточность информационных систем:
использование нескольких систем на
различных этапах работы с должниками и их
задолженностями.
– Высокий риск ошибки при работе.
– Распределенность электронных документов
– отсутствие единого места хранения
информации.
– Ручное формирование электронных
архивов на сетевых расположениях внутри
объектов.
– Сложность распределения задач по
исполнителям – неактуальные данные о
рабочей нагрузке исполнителей, об их
отсутствии на рабочих местах.
– Сложность мониторинга рабочей
деятельности и подведения общих
результатов – необходимость сбора
совокупной информации о результатах
деятельности с нескольких ресурсов.
21
Бизнес-роли
1) Руководитель
коллекторского
направления
Продолжение таблицы 4
«Узкие места»
Отсутствие
комплексной
автоматизации
деятельности
специалиста (И-2)
Отсутствие
регламентов
взаимодействия с
заемщиками (О-1)
Отсутствие
внутренних
регламентов
взаимодействия
сотрудников
коллекторского
направления (О-2)
Потенциальные риски
– Длительность и рутинность исполнения
этапа работ: взаимодействие с должниками,
оформление документов различных форматов
и фиксация результатов деятельности.
– Низкий уровень актуальности данных по
должникам и их задолженностям.
– Избыточность информационных систем:
использование нескольких систем на
различных этапах работы с должниками и их
задолженностями.
– Высокий риск ошибки исполнителя этапа
работ при исполнении взаимодействия с
должниками и формировании сопутствующих
документов.
– Распределенность электронных документов
– отсутствие единого места хранения
информации.
– Ручное формирование электронных
архивов на сетевых расположениях внутри
объектов.
– Сложность фиксации промежуточных
результатов – возможные ошибки или потери
данных.
– Потеря времени на повторное исполнение
взаимодействия.
– Возможное несоблюдение
законодательства предметной области,
которое ведет к серьезным штрафным
санкциям и приостановлению рабочей
деятельности объекта.
– Рутинность внутренних организационных
бизнес-процессов.
– Длительность взаимодействия между
сотрудниками при совместной работе в
процессе взаимодействия с должниками и при
работе с задолженностями и сопутствующими
документами.
Бизнес-роли
1) Специалист
коллекторского
направления
1) Специалист
коллекторского
направления
1) Руководитель
коллекторского
направления
2) Специалист
коллекторского
направления
Вышеописанные узкие места и их последствия (потенциальные риски)
оказывают негативное влияние на рабочую деятельность структурных
подразделений коллекторского направления объектов автоматизации, что ведет
к сокращению финансовых показателей и экономической эффективности в
целом.
22
23
Рисунок 6 – Диаграмма Исикавы предметной области
2 АНАЛИЗ И ВЫБОР ПРОЕКТНЫХ РЕШЕНИЙ ДЛЯ РАЗРАБОТКИ
ЦЕЛЕВОЙ АРХИТЕКТУРЫ ПРОЕКТА
2.1 Анализ функциональных возможностей аналогов программного
комплекса
В процессе исследования предметной области был проведен анализ
функциональных
возможностей
ИС-аналогов
с
целью
формирования
функционала конечных пользователей программного комплекса «RU-Collector».
Для анализа было выбрано 6 наиболее распространенных ИС, таких как:
«FIS Collection» (ООО «Финансовые информационные системы», «МФС
Коллекшн» (Группа компаний «А-Дата»), «Контакт» (ООО «Люксбэйс» и ООО
«Криф»),
«Автоматизация
«WS.Коллекторское
деятельности
агентство»
КА»
(ООО
(ООО
«ЦМД-софт»),
«Программные
системы»),
«БИТ:Управление задолженностью» (ООО «Первый бит»). Результаты данного
исследования приведены в таблице В.1 приложения В [9, 21, 31, 32, 37, 38].
В качестве параметров исследования данных ИС были определены:
– минимальные
стоимостные
границы,
включающие
расходы
на
внедрение и 1 месяц автоматизации на минимальное число пользователей (1
месяц автоматизации и минимальный пакет часов сопровождений);
– вид информационной системы;
– функциональные возможности в разрезе стадий взыскания, а также
основной и дополнительный функционал;
– интеграционные возможности.
По результатам анализа вышеуказанных ИС, наиболее полным спектром
функциональных возможностей наделена ИС «FIS Collection», что объясняет
высокую величину ее стоимости.
24
2.2 Анализ и обоснование технологий и платформ проектирования
архитектуры программного комплекса
При проектировании архитектуры программного комплекса «RUбыли
Collector»
использованы
несколько
современных
методологий
проектирования, каждая из которых отображает с различных сторон предметную
область
данной
диссертации.
Перечень
технологий
проектирования
и
используемые среды представлены в таблице 5 [22, 23, 24].
Таблица 5 – Технологии и платформы проектирования архитектуры
программного комплекса «RU-Collector»
Методология
IDEF0
BPMN 2.0
UML 2.0
При
использован
Краткое описание методологии
Нотация графического моделирования, используемая
для создания функциональной модели, отображающей
структуру и функции системы, а также потоки
информации и материальных объектов, связывающих
эти функции.
Язык моделирования бизнес-процессов, который
является промежуточным звеном между
формализацией/визуализацией и воплощением бизнеспроцесса
Язык графического отображения для объектноориентированного моделирования, используемого при
разработке ПО.
проектировании
веб-сервис
интерфейсов
«Balsamiq
программного
Mockups»,
Среда
проектирования
Erwin,
модуль
«Process
Modeler».
Enterprise
Architect
StarUML
комплекса
который
был
позволяет
прототипировать экранные формы ИС с низкой степенью детализации [25].
2.3 Обоснование выбора технологий и платформ для реализации
архитектуры программного комплекса
Программный комплекс «RU-Collector» является облачным инструментом
автоматизации и в качестве базовых ЯП были использованы:
1) JavaScript – последовательность действий, представляющая собой
программный код, в основу создания которого положено динамическое
управление объектами HTML-документов [30].
25
2) PL/SQL (Programming Language for SQL) – ЯП от компании Oracle,
предоставляющий средства для сложной обработки данных [29]. Язык является
собственным расширением SQL и предлагает использовать в БД процедуры и
пакеты, увеличивая возможность повторного использования кода и его
производительность [28].
Язык программирования JavaScript используется в front-разработке
программного комплекса «RU-Collector», а язык PL/SQL – в back-разработке.
Для реализации архитектуры ПК «RU-Collector» были применены:
1) Среды разработки программного кода:
– Oracle SQL Developer – интегрированная среда разработки ПО,
используемая в традиционных и в облачных ИС [52]. В качестве ключевых
особенностей определены: возможность описания объектов, использование
встроенного помощника кода и подсказок компилятора, построение и хранение
кода в заданной иерархии, возможность его рефакторинга, использование
функционально обширных готовых библиотек [53].
– Node.js – среда разработки масштабируемых сетевых ИС на языке
JavaScript [51]. Платформа позволяет писать серверный код для динамических
веб-страниц и веб-приложений.С помощью Node.js реализуется парадигма
«JavaScript
для
всего»,
предполагающая
использование
одного
языка
программирования для front- и back-разработки [19].
– React.js – декларативная и эффективная JavaScript библиотека для
создания пользовательских интерфейсов. Она позволяет выстраивать сложный
пользовательский интерфейс из маленьких изолированных частей кода [11].
Также, в качестве редактора кода используется среда «WebStorm», которая
работает с современным JavaScript, поддерживает интеграцию с Git. Она
позволяет
писать
качественный
быстрый
код
посредством
высокой
продуктивности работы и различным интеллектуальным функционалом [56].
2) СУБД
Oracle
Database
–
объектно-реляционная
система,
обеспечивающая управление над созданием и использованием БД. Она имеет
26
возможности
высокой
нагрузки
и
масштабируемости,
автоматического
распределения ресурсов хранения данных и доступа к ним [27].
3) Среда контроля версионности программного кода Git – распределенная
система контроля версий и управления исходным кодом, которая записывает
изменения в файл или набор файлов в течение времени и позволяет вернуться
позже к определённой версии [12, 48]. В качестве преимуществ Git выделяют:
бесплатный и открытый исходный код, резервное копирование, безопасность
хранимых данных, исключение необходимости работы с профессиональным
сетевым оборудованием, легкость ветвления данных [48].
2.4 Обоснование целевой архитектуры программного комплекса
2.4.1 Архитектура данных
Архитектура данных программного комплекса «RU-Collector» базируется
на следующих сущностях:
1) База данных – совокупность массивов и файлов данных, организованная
по определённым правилам, предусматривающим стандартные принципы
описания, хранения и обработки данных независимо от их вида. В качестве
примера можно выделить БД должников и требований [10].
2) Системные сущности, которые строго определены в программном коде
и имеют ряд собственных характеристик и параметров, а также варианты
поведения и взаимодействия с другими сущностями. К системным сущностям
можно отнести: подразделения, пользователи, роли доступа, кредитор, должник,
требования, портфели
требований, наборы
требований,
задолженности,
мероприятия, стратегии взыскания и т.д. Системные сущности хранятся в БД.
3) Программные решения, программные сервисы, бизнес-процессы и
реализации. Наиболее подробное описание данных сущностей представлено в
пункте 1.3. В качестве примеров можно обозначить:
– программное решение – «Разработка стратегии дистанционного
взаимодействия»;
– бизнес-процесс – «Email-оповещение»;
27
– реализация – «Рассылка Email-оповещений через программный
комплекс»;
– программный сервис – «Организация взаимодействия с ЕФРСБ».
4) Справочники – набор данных, регламентированный табличной формой
с определенным количеством колонок. Данный вид сущности определен в
разрезе ПК «RU-Administrator», хранимые в них данные используются
конечными пользователя ПК «RU-Collector» В качестве примера справочников
можно
выделить:
«Задолженности»,
«Операции
по
задолженностям»,
«Процентные периоды», «Получатели».
2.4.2 Архитектура приложений
Комплексная автоматизация деятельности по возврату просроченных
задолженностей
подразумевает
с
помощью
программного
необходимость
комплекса
применения
группы
«RU-Collector»
взаимосвязанных
программных комплексов с помощью протоколов Https (протокол передачи
данных, позволяющий клиенту и серверу сначала установить зашифрованное
соединение, а затем отправлять по нему HTTP-сообщения) и Websocket
(стандартизированный протокол, который связывает веб-серверы и клиенты в
режиме реального времени) [44, 55].
Архитектура приложений предметной области представлена на рисунке 4.
Изначально, объекту автоматизации необходимо зарегистрировать свою
организацию в одном из программных комплексов.
«RU-Controller» – программный комплекс, который направлен на
управление
финансовой
составляющей
автоматизации
коллекторского
направления с помощью программного комплекса «RU-Collector». Его
функционал предназначен для руководителей организаций или подразделений,
которые
отвечают
за
финансирование
автоматизации.
В
разрезе
зарегистрированной организации доступны следующие возможности: работа с
данными организации и собственными персональными данными; просмотр
пользовательской документации; взаимодействие с сотрудниками технической
28
поддержки ООО «КРДС» посредством диалогов; ознакомление с описанием
возможных для подключения программных комплексов, программных решений
и сервисов, а также реализаций; ознакомление и выбор тарифных планов.
На следующем этапе, после регистрации организации, необходимо создать
администратора программных комплексов.
«RU-Administrator» – программный комплекс, который направлен на
осуществление всестороннего администрирования программного комплекса
«RU-Collector».
Данный
комплекс
является
инструментом
ИТ-служб
организации [33]. В качестве функциональных возможностей администратора
реализованы: настройка сотрудников и ролей доступа, подразделений и режимов
работ; работа со стратегиями взыскания и с мероприятиями в разрезе их времени
исполнения, реквизитного состава и используемых при исполнении шаблонов;
управление видами задолженностей; настройка интеграционных возможностей
со сторонними ИС.
В результате администрирования у конечных пользователей появляется
возможность начала работы в программном комплексе «RU-Collector».
«RU-Collector» – программный комплекс, состоящий из широкого спектра
решений и сервисов, направленных на автоматизацию взаимодействия
коллектора и должника на всех стадиях взыскания – SOFT-, HARD- и LEGALCollection. Программный комплекс предназначен для работы в нем таких
конечных пользователей, как руководители и сотрудники отделов по
взаимодействию с должниками [33]. В качестве функциональных возможностей
конечных пользователей реализованы работа с портфелями требований и
требованиями; выстраивание и назначение стратегии; исполнение различных
видов взаимодействия с должниками и фиксация результатов, планирование и
перепланирование рабочей нагрузки исполнителей, ведение учета движения
денежных средств и проверка должников в различных открытых реестрах.
29
30
Рисунок 7 – Архитектура приложений предметной области
2.5 Механизмы защиты информации в программном комплексе
В ходе разработки программного комплекса «RU-Collector» выявлены
некоторые типы угроз информационной безопасности, которые характеризуются
соответствующими последствиями. Типы возможных угроз, их последствия и
актуальность представлены в таблице 6.
Таблица 6 – Перечень угроз и возможные последствия от их реализации
Тип угрозы
Несанкционированный
доступ к КИ
Копирование КИ на
личные портативные
носители
Модификация или
удаление информации
Работа на сайтах с
неподтвержденным
режимом безопасности
Разглашение КИ
Перехват информации
Внедрение вредоносного
ПО
Возможные последствия
Модификация, удаление, копирование, КИ,
завладение БД и передача данных третьим
лицам.
Использование КИ в личных корыстных
целях, разглашение и рассекречивание
третьим лицам.
Использование недостоверных данных, потеря
информации, невозможность выполнения
должностных обязанностей в связи с
отсутствием информации и файлов.
Фишинг, отслеживание действий
пользователя, заражение ПК вирусами,
использование сетевых ресурсов и интернет трафика, установка рекламных программ,
кража КИ.
Использование КИ в личных корыстных
целях, возможность совершения
мошенничества с полученной информацией.
Подмена адресата получателя, замена файлов
с КИ, удаление и изменение данных,
рассекречивание КИ с возможностью
передачи третьим лицам или использованием
в корыстных целях.
Ошибки в работе ПК и ПС, удаление и
модификация файлов, замена файлов,
невозможность работы с документами, вывод
техники из строя, заражение ПК вирусами,
фишинговые атаки, хищение КИ.
Актуальность
угрозы
Актуально
Актуально
Актуально
Неактуально
Актуально
Актуально
Неактуально
В качестве категорий нарушителей угроз информационной безопасности
на объектах автоматизации были определены: внешний и внутренний.
Подробное описание категорий возможных нарушителей представлена в
таблице 7.
31
Таблица 7 – Категории потенциальных нарушителей
Категория
Характеристика
нарушителей
Внешние
Фирмы-конкуренты
нарушители
Уволенные сотрудники
Внутренние
нарушители
Сотрудники –
непосредственные
пользователи ПК «RUCollector»
Сотрудники из других
структурных
подразделений
Сотрудники объектов
автоматизации из ИТподразделений
Возможности потенциальных
нарушителей
Удаленное подключение, в следствии чего
возможность установки вредоносных программ,
запуск вирусов, копирование/модификация/
удаление данных клиентов, завладение
информацией о пользователях системы.
Удаление, изменение программного кода ИС.
Завладение данными аутентификации и
перенастройка прав доступа и
функционирования.
Завладение КИ, ее использование в личных
корыстных целях, модификация и удаление
данных, несанкционированная выгрузка баз
данных.
Установка программ с вирусами, установка
нелицензионного ПО, неправильность
разграничения доступа к информации,
использование слабых средств защиты
информации, разглашение конфиденциальных
данных пользователей ИС, копирование базы
данных и ее использование в личных
(корыстных) целях, удаление данных.
На основе приведенных в таблицах 8 и 9 данных, можно сделать вывод,
что для программного комплекса «RU-Collector» актуальными угрозами
являются следующие: несанкционированный доступ к КИ, копирование КИ на
личные портативные носители, модификация или удаление информации,
разглашение КИ, перехват информации.
Для исключения возможного возникновения данных угроз на объектах
автоматизации рекомендуется поддерживаться рекомендаций:
1) Пользователи программного комплекса «RU-Collector» должны:
– соблюдать правила «чистого стола» и «чистого экрана»;
– использовать сложные и уникальные пароли;
– осуществлять блокировку экрана;
– быстро реагировать на подозрительное поведение своих персональных
компьютеров.
32
2) ИТ-службы организаций должны:
– следить за работой антивирусных программ;
– Следить
за
поведением
пользователей
при
исполнении
своих
должностных обязанностей использованием их личных съемных носителей;
– исключать возможность перехода пользователей на вредоносные сайты
и установки стороннего ПО для использования в личных целях;
– использовать политику разграничения прав доступа во внешние и
внутренние ресурсы пользователей.
3) Проведение
организационных
собраний
с
целью
напоминания
сотрудникам следующего:
– политик конфиденциальности;
– регламентов обращения с техническим и программным обеспечением;
– правил неразглашения данных третьим лицам и других внутренних
регламентов организаций [35].
33
3 ПРОЕКТИРОВАНИЕ
КОМПЛЕКСА
АРХИТЕКТУРЫ
ПРОГРАММНОГО
3.1 Модели предметной области TO-BE
3.1.1 Техническая и программная модели
Техническая модель определяет рекомендации по составу технических
средств, которым должны обладать конечные пользователи на объектах
автоматизации. Техническая модель предметной области представлена в таблице
Г.1 приложения Г.
Перечень технических устройств носит рекомендательный характер для
объектов автоматизации и исключает необходимость владения всем перечнем
технических средств.
Программная модель предметной области TO-BE включает в себя
необходимое
базовое
и
прикладное
ПО,
которым
должны
обладать
автоматизированные рабочие места конечных пользователей программного
комплекса «RU-Collector». В таблице Г.2 приложения Г представлен перечень
программного обеспечения предметной области.
В зависимости от возможностей бизнеса и ИТ-регламентов определенного
объекта автоматизации, на автоматизированных рабочих местах пользователей
могут
быть
дополнительно
установлены:
IP-телефония,
SMS-центры,
информационно-справочные системы для отделов LEGAL-Collection, системы
автоматизированной печати и другие пакеты прикладной направленности.
3.1.2 Концептуальная модель
Концептуальная модель TO-BE, как и модель AS-IS, выполнена в нотации
IDEF0 и отражает смысловую структуру предметной области в рамках ее
автоматизации посредством программного комплекса «RU-Collector». На
рисунке 8 представлена концептуальная модель предметной области TO-BE.
34
Рисунок 8 – Концептуальная модель предметной области TO-BE
Блок управления и нормативно-правовой базы концептуальной модели
TO-BE полностью соответствует модели AS-IS, представленной в пункте 1.6.2.
Блок входной информации содержит 4 ветвей: БД должников и
требований, в том числе кредитные договора, если их наличие необходимо
(информационный вид), БД платежей (информационный вид), суммы выданных
в кредит ДС (денежный вид), отчетная информация по выполненным
взаимодействиям с должниками (документальный вид).
Блок выходной информации содержит 4 ветви: Требования в статусе
«Закрыто» (информационный вид), электронный архив данных – требования,
история взаимодействий, документы и т.д. (информационный вид), прибыль от
погашенных задолженностей (денежный вид), отчетные формы по результатам
деятельности (документальный вид).
35
3.1.3 Модель бизнес-процесса
В рамках этапа проектирования архитектуры ПК «RU-Collector» построена
обобщенная модель верхнеуровнего бизнес-процесса «Взаимодействие с
должником по вопросам возврата просроченных задолженностей» TO-BE.
Бизнес-процесс отображает последовательность этапов взаимодействия с
должниками в разрезе функциональных возможностей ПК «RU-Collector».
В качестве бизнес-ролей предметной области выделены – «Отделы по
возврату просроченных задолженностей» и «Кредитный отдел». Данный роли
могут
характеризоваться
как
внутренние
(в
ситуации,
когда
выдача
кредитов/займов и возврат просроченных задолженностей осуществляется
организационными структурами одной организации), так и внешние (в случае,
когда деятельность по возврату задолженностей передается сторонним
юридическим лицам).
Перечень документов, участвующих в бизнес-процессе TO-BE верхнего
уровня представлен в таблице 7, а его описание – в таблице Д.1 приложения Д.
Таблица 8 – Перечень документов бизнес-процесса «Взаимодействие с
должником по вопросам возврата просроченных задолженностей» TO-BE
Наименование документа
Портфель требований
Отчетность по результатам
взаимодействия
Краткое описание документа
Совокупность различного вида
данных о должниках, их
кредитах и задолженностях, а
также исполненных вариантах
взаимодействия с ними.
Результаты деятельности по
взаимодействию с должниками
с учетом изменений данных о
должнике, его кредитах и
задолженностях.
Тип документа
Бумажный и/или
Электронный
Бумажный и/или
Электронный
Графическое представление бизнес-процесса TO-BE представлено на
рисунке 9.
36
Рисунок 9 – Бизнес-процесс «Взаимодействие с должником по вопросам
возврата просроченных задолженностей» TO-BE
Бизнес-процесс TO-BE исключает все «узкие места», выявленные на этапе
анализа предметной области в бизнес-процессе AS-IS.
3.1.4 Модель вариантов использования
Диаграмма
вариантов
использования
демонстрирует
варианты
использования функциональных возможностей программного комплекса «RU-
37
Collector» в разрезе каждого пользователя. Данный вид диаграммы позволяет
концептуально представить реализованное программное решение.
Диаграмма вариантов использования предметной области представлена на
рисунке 10.
Программный комплекс «RU-Collector» отображен в виде множества
актеров, взаимодействующих с системой с помощью так называемых вариантов
использования.
В качестве объектов «Actor» выделены руководители и сотрудники
отделов, которые, в свою очередь обобщены в соответствующие сущности –
«Руководитель» и «Сотрудник отдела».
Вариант использования – это спецификация сервисов (функций), которые
система
предоставляет
актеру.
Каждая
обозначенная
сущность
имеет
собственный ряд доступного функционала в программном комплексе «RUCollector», который может быть не доступен или доступен частично другому
виду сущностей [14].
На представленной ниже диаграмме вариантов отображены следующие
виды взаимосвязей
1) Отношение типа «ассоциация» определяет взаимодействие актеров с
вариантами использования.
2) Отношение типа «обобщение» обозначены линиями с пустыми
стрелками и показывают группировку сущностей в обобщенные группы.
3) Отношения типа «зависимость» обозначены пунктирными линиями и
определяют взаимосвязи между вариантами использования (программными
решениями), а блоки пояснения отображают характер взаимосвязей.
38
39
Рисунок 10 – Модель вариантов использования ПК «RU-Collector»
3.1.5 Модели состояний
Модели состояний были спроектированы в нотации UML и отображают
последовательность переходов сущностей из одного состояния в другое с
помощью системных статусов [43].
В процессе проектирования и разработки архитектуры программного
комплекса «RU-Collector» спроектированы две модели состояний для базовых
системных сущностей – «Требование» и «Мероприятие», представленные на
рисунках 11 и 12.
Для каждого состояния (в данном случае статуса) системной сущности
программного комплекса «RU-Collector» присутствуют следующий список
действий:
entry – действие, которое выполняется в момент входа в состояние;
do – действие, которое выполняется в течение этого состояния;
exit – действие, которое выполнятся в момент выходя из состояния [43].
Системная
сущность
«Требование»
имеет
три
статуса.
Статус
«Корректное» предоставляет пользователю право на применение всего
доступного функционала ПК в отношении данного требования, а статусы
«Закрытое»
и
«Некорректное»
ограничивают
определенную
группу
функционала пользователя, например: ограничение на выстраивание стратегий,
внесения данных о любых движениях ДС.
Системная сущность «Мероприятие» имеет 7 статусов, исходя из которых
пользователь может проанализировать результаты взаимодействия с должником.
Данные статусы применимы к любого рода мероприятиям, как системным, так и
пользовательским.
40
41
Рисунок 11 – Модель состояний системной сущности «Требование»
42
Рисунок 12 – Модель состояний системной сущности «Мероприятие»
3.1.6 Модель компонентов
Проектирование структуры компонентов вычислительной сети было
выполнено с помощью нотации UML 2.0 в представлении диаграммы
компонентов.
Данная диаграмма демонстрирует элементы и компоненты программного
комплекса
«RU-Collector»,
существующих
на
этапе
исполнения
его
функциональных возможностей [54].
На рисунке 13 представлена обобщенная диаграмма развертывания в
рамках
решения
задачи
по
автоматизации
возврата
просроченной
задолженности.
Рисунок 13 – Диаграмма компонентов предметной области
На диаграмме компонентов в качестве сущностей обозначены
1) Узлы – это то, что может содержать программное обеспечение [18]. К
узлам относятся: ПК пользователя, Fronted-сервер, Oracle-сервер.
2) Компоненты – физические сущности, реализующие некоторый набор
интерфейсов и служащие для общего обозначения элементов физического
представления модели [16]. К компонентам относятся: web-контейнер, oracle
database express edition, web-браузер.
43
3.2 Проектирование архитектуры базы данных
Архитектура базы данных программного комплекса «RU-Collector»
спроектирована с помощью диаграммы классов в нотации UML, которая служит
для представления статической структуры модели системы в терминологии
классов объектно-ориентированного программирования [15].
На рисунке Е.1 приложения Е представлена спроектированная архитектура
базы данных программного комплекса.
На диаграмме отображены сущности базы данных – классы. Каждый класс
имеет:
– наименование;
– набор атрибутов (в том числе первичный ключ), включающих в себя
различные характеризующие его данные;
– операции и методы, которые характеризуют функциональный аспект
поведения класса.
Взаимодействие между классами отображается с помощью отношений
ассоциации, зависимости, обобщения и реализации. Каждое из этих отношений
имеет собственное графическое представление на диаграмме [15].
3.3 Проектирование интерфейсной части
На этапе построения архитектуры ПК «RU-Collector» выполнено
прототипирование пользовательских интерфейсов с помощью онлайн-сервиса
Balsamiq Mockaps [25].
Прототипы интерфейсов отображают общие возможности в разрезе
программных решений и программных сервисов ПК «RU-Collector».
Графическое представление главных интерфейсов программного решения
представлено на рисунках 14-22.
Интерфейс авторизации, изображенный на рисунке 14, помимо полей
ввода содержит контактную информацию, по которой может осуществляться
связь пользователя с командой разработчиков ООО «КРДС», также имеется
44
возможность заполнить форму обратной связи и перейти к инструкциям
пользователей.
После успешной авторизации пользователя, в веб-браузере отображается
интерфейс «Главная», представленный на рисунке 15. Интерфейс содержит
личные данные пользователя, которые можно изменить при необходимости.
На рисунке 16 приведен процесс внесения должников и их анкетных
данных в ПК (создание портфелей и требований) с целью дальнейшего
взаимодействия
с
должниками
по
вопросам
возврата
просроченных
задолженностей.
После того, как база должников внесена в ПК пользователю доступен
функционал по выстраиванию стратегий взыскания единично в разрезе
конкретного требования или массово – по портфелю. На рисунках 17 и 18
представлены интерфейсы программного решения «Выстраивание стратегии».
По результатам определения и назначения стратегий взыскания, у каждого
пользователя формируется личный план работ, отображенный на рисунке 19.
План работ может быть представлен помесячно, недельно или за определенный
день.
Исполнение
каждого
мероприятия
соответствует
определенному
временному интервалу, которое учитывается при выстраивании стратегии.
По нажатию на мероприятие в программном решении «Исполнение
мероприятий» запускается интерфейс карточки исполнения, представленный на
рисунке 20. Данный интерфейс содержит группу реквизитов, необходимую для
исполнения
определенного
вида
мероприятия
(реализации),
а
также
дополнительные сведения по требованию.
На рисунке 21 представлено программное решение «Движение денежных
средств», направленное на работу с разными видами задолженностей в разрезе
требований и фиксацию различного характера движения денежных средств.
Для контроля исполнения рабочей деятельности всеми исполнителя
предусмотрен функционал для руководителя, изображенный на рисунке 22. Его
вид подобен программному решению «Исполнение мероприятий», а данные
календаря отображают статистические показатели.
45
Рисунок 14 – Интерфейс «Авторизация сотрудника»
Рисунок 15 – Интерфейс «Главная»
46
Рисунок 16 – Интерфейс программного решения «Внесение требований»
Рисунок 17 – Интерфейс программного решения
«Выстраивание стратегии по требованию»
47
Рисунок 18 – Интерфейс программного решения
«Выстраивание стратегии по портфелю»
Рисунок 19 – Интерфейс программного решения «Исполнение мероприятий»
(календарь исполнителя)
48
Рисунок 20 – Интерфейс программного решения «Исполнение мероприятий»
Рисунок 21 – Интерфейс «Движение денежных средств» в ПК «RU-Collector»
(общий массив)
49
Рисунок 22 – Интерфейс «План работ» в ПК «RU-Collector»
(календарь подразделения)
Детальное
представление
прототипов
интерфейсов
программного
комплекса «RU-Collector» представлено в приложении Ж.
3.4 Информационное обеспечение задачи
Информационное обеспечение задачи предметной области можно
классифицировать на две группы.
1) Внутримашинное информационное обеспечение:
– База данных программного комплекса «RU-Collector» (СУБД Oracle
Database). Она относится к типу реляционных баз данных и включает в себя
различныю структурированную информацию, представляемую в виде таблиц и
хранящихся
в
них
сущностей.
Также,
база
данных
регламентирует
взаимоотношения между сущностями и хранит правила взаимодействия между
ними.
50
– Государственные
классификаторы
и
базы
данных,
которые
представлены в форматах Microsofr Excel, XML или получаемые по интеграции
через
открытие
интегрируемы
с
или
закрытые
интерфейсы
программным
комплексом:
API.
Используемые
классификатор
базы
субъектов
Российской Федерации (регионы, города, улицы и дома), база данных
Федеральной службы судебных приставов и Единого федерального реестра
сведений о банкротствах физических и юридических лиц.
2) Внемашинное информационное обеспечение:
– Различные
микрофинансовой
классификаторы
областей,
коллекторской,
используемые
в
банковской
предметной
области
и
–
классификаторы задолженностей, отделов судебных приставов, судов и другое.
– Стандарты отчетности и документации, формируемой как внутри
отделов взыскания задолженностей (между сотрудниками), так и для других
организационных
структур
в
разрезе
каждого
(директората, бухгалтерии, отдела рисков и другое).
51
объекта
автоматизации
4 РАЗРАБОТКА
И
ТЕСТИРОВАНИЕ
ПРОГРАММНОГО КОМПЛЕКСА
АРХИТЕКТУРЫ
4.1 Разработка архитектуры программного комплекса
В качестве листинга кода программного комплекса «RU-Collector»
представлены выжимки программного кода, написанного на платформе
«WebStorm» [56].
Реализация пользовательского функционала ПК «RU-Collector» велась
исходя
из
взаимосвязи
программных
решений
и
в
следующей
последовательности: «Внесение требований», «Выстраивание стратегии»,
«Исполнение мероприятий», «План работ» и «Движение денежных средств».
В приложении И на рисунках И.1-И.10 представлен листинг программного
кода с разделением на front- и back-разработку.
Первый вид регламентирует разработку, связанную с построением дизайна
и веб-интерфейсов программного комплекса. В процессе его реализации
закладывается логика работы программного решения исходя из взаимодействия
конечных пользователей с возможным функционалом. В процессе frontразработки был использован ранее обозначенный язык программирования
JavaScript [47].
Второй вид разработки, определяемый как back и базирующийся на языке
PL/SQL, направлен на построение архитектуры серверной части программного
комплекса, а также разработки интеграционных возможностей с различными
сторонними информационными системами [45].
В процессе написания программного кода, на основе регламентов
разработки ООО «Компания развития доступных систем», было выполнено его
комментирование для оптимизации дальнейшей работы с ним. Также,
разработка программного комплекса «RU-Collector» велась по правилам
версионности программного кода.
52
4.2 Разработка пользовательской документации к программному
комплексу
Пользовательская документация ПК «RU-Collector» была реализована с
помощью wiki-документации через сервис «DokuWiki», который совместим со
стандартами и предназначен в первую очередь для создания понятной
документации любого характера [46].
В качестве языка разработки документации был использован язык
упрощенной разметки «Markdown», который легок в написании и работе и, при
необходимости, который может быть перекомпилирован в HTML [50].
Для разработки пользовательской документации был выделен отдельный
ресурс, содержащиеся данные в котором доступны только авторизованному
пользователю. Посетителю ресурса не доступен функционал авторизации и
создания документации. Язык «Маркдаун» реализует различного типа
заголовки, нумерацию и выделения текста, а также способен использовать
графические файлы.
На рисунках К.1-К.12 приложения К представлен процесс разработки
пользовательской документации для ПК «RU-Collector» [49].
В процессе создания документации изначально была реализована иерархия
папок и страниц, содержащих в себе соответствующие разделы документации
для пользователей. Далее были определены общие параметры и вид
представляемой информации в документации для поддержания целостности и
однотипности данных. На заключительном этапе были заполнены разделы
документации текстом и графическими рисунками, которые будут понятны
конечным пользователям.
Документация пользователей доступна в программном комплексе на
любом интерфейсе по нажатию на кнопку «Помощь», после чего в новом окне
браузера
запускается
интерфейс
определенного
раздела
документации,
соответствующего запущенному интерфейсу на экране пользователя в ПК «RUCollector». Пользовательский вид документации представлен на рисунках Л.7Л.12 приложения Л.
53
4.3 Тестирование
функциональных
возможностей
программного
комплекса
Тестирование
ПК
«RU-Collector»
проводилось
со
стороны
функциональных возможностей пользователей. Результаты тестирования
представлены на рисунках 23-39 [34].
Контроль активности пользователей в ПК происходит с помощью
ограничений
сессий.
После
определенного
времени
неактивности
ПК
перенаправляет пользователей на интерфейс авторизации и просит повторно
авторизоваться (рисунок 23).
Рисунок 23 – Контроль активности пользователей в программном комплексе
В
случае,
когда
пользователем
введены
некорректные
данные
авторизации, то ПК уведомляет его об этом с помощью системного уведомления.
Количество попыток авторизации не ограничено. Пример поведения ПК в случае
некорректного ввода при авторизации пользователя представлен на рисунке 24.
54
Рисунок 24 – Ошибка авторизации пользователя
На рисунке 25 представлено системное уведомление о некорректности
требования, которое возникает в случае, когда пользователь заполнил не все
обязательные реквизиты.
Рисунок 25 – Сохранение некорректного требования
55
В случае, когда внесенное требование имеет статус «Некорректно», ПК
ограничивает часть функциональных возможностей пользователя по отношению
к данному требованию, как показано на рисунках 26 и 27.
Рисунок 26 – Ограничение работы пользователей с некорректными
требованиями
Рисунок 27 – Ограничение работы пользователей с закрытыми требованиями
Также, для удобства пользователей, некорректные требования в общем
массиве выделяются цветом (рисунок 28).
56
Рисунок 28 – Выделение закрытых требований для удобства пользователей
Для
работы
пользователя
с
реквизитным
составом
требований
реализованы маски ввода на некоторые реквизиты. В качестве масок ввода
используется ограничения на количество вводимых цифр, использование
специальных символов, букв и цифр при вводе данных. На рисунках 29 и 30
представлены пример масок ввода в реквизитах «СНИЛС» и «Электронная
почта».
Рисунок 29 – Реализация масок ввода на реквизитах
57
Рисунок 30 – Ограничение по вводимым значениям в зависимости от
установленных масок ввода
Исходя из ролей и прав доступа, присваиваемых пользователям при их
создании, и регламентов 230-ФЗ, реализованы ограничения на исполнение
мероприятий, представленные на рисунках 31 и 32.
Рисунок 31 – Ограничение на исполнение мероприятий
58
Рисунок 32 – Ограничение по взаимодействию с должниками по 230-ФЗ
Также, работа пользователей в ПК регламентируется установленными на
подразделениях часами работ, что позволяет не превышать стандарты их рабочей
нагрузки и переработку (рисунок 33).
Рисунок 33 – Ограничение на рабочую деятельность пользователей исходя из
установленных режимов работы
59
В процессе исполнения должностных обязанностей в ПК у пользователей
с помощью различных цветов выделяется факт исполнения конкретного
мероприятия, как показано на рисунке 34.
Рисунок 34 – План работ конкретного пользователя
Движение денежных средств и работа с имеющимися просроченными
задолженностями в разрезе каждого требования регламентируется нормативноправовыми аутами РФ. На рисунке 35 представлен контроль и автоматическое
распределение платежей в зависимости от приоритетов гашения.
Рисунок 35 – Автоматическое распределение платежей
60
Также, в ПК реализована фиксация факта переплаты должником платежей
для дальнейшего возврата средств (рисунок 36) и автоматический контроль
периодов расчета для исключения двойного начисления процентов (рисунок 37).
Рисунок 36 – Контроль гашений на переплаты должником
Рисунок 37 – Ограничение на пересечение периодов у задолженностей
61
В
процессе
работы
с
задолженностями
пользователем
доступен
функционал удаления. В случае, если рассчитанные задолженности учтены в
итоговой сумме остатков, то пользователю необходимо подтвердить их
удаление, как показано на рисунке 38.
Рисунок 38 – Уведомление перед удалением расчетных сумм задолженностей
Также, реализован особый алгоритм учета задолженностей, что исключает
возможность появления некорректных сумм задолженностей (рисунок 39).
Рисунок 39 – Невозможность учета задолженностей без их расчета
62
Заключение
По результатам написания магистерской диссертации была реализована и
описана архитектура программного комплекса «RU-Collector», разработанного
ООО «Компания развития доступных систем». Программное решение
полностью
соответствует
требованиям
ФССП,
предъявляемым
к
коллекторскому ПО.
В процессе реализации поставленных к диссертации задач были
выполнены все необходимые этапы проектирования и разработки архитектуры
программного решения, а именно:
В первой главе проведен анализ предметной области и потенциальных
объектов автоматизации:
– представлены
типовые
организационные
структуры
банка,
микрофинансовой организации и коллекторского агентства;
– освещена теоретическая и терминологическая составляющая процесса
взыскания долговых обязательств;
– спроектированы и описаны модели AS-IS;
– сформулированы
и
графически
интерпретированы
проблемы
предметной области.
В рамках второй главы выполнены следующие этапы работ:
– анализ
программного
существующих
комплекса
информационных
«RU-Collector»,
систем
действующих
на
–
аналогов
российском
финансовом рынке;
– определены и обоснованы технологии и платформы проектирования с
помощью которых будет представлена архитектура программного решения;
– приведено описание выбранных технологий и платформ, используемых
при реализации программного решения;
– представлено обоснование целевой архитектуры в разрезе архитектуры
данных и приложений;
63
– определены
механизмы
защиты
информации,
хранящейся
и
обрабатываемой в программном комплексе «RU-Collector».
В
третьей
главе
представлен
процесс
проектирования
целевой
архитектуры программного решения:
– описан программный комплекс посредством графической и текстовой
интерпретации его возможностей;
– спроектирована и описана модель базы данных с указанием сущностей,
набора их атрибутов и связей;
– графически интерпретированы и описаны интерфейсы программного
решения;
– представлено внутримашинное и внемашинное информационное
обеспечение.
В
последней
четвертой
главе
описана
реализация
архитектуры
программного комплекса «RU-Collector»:
– продемонстрирован процесс разработки посредством описания frontedи back-программного кода;
– представлена
и
описана
пользовательская
документация
к
программному решению, которая содержит описание всех функциональных
возможностей;
– освещен этап тестирования реализованного функционала программного
комплекса «RU-Collector».
По результатам выполнения выпускной квалификационной работы были
выполнены все поставленные задачи и достигнута цель.
Программный комплекс «RU-Collector» передан в опытное тестирование
нескольким потенциальным объектам автоматизации с целью оптимизации
реализованных возможностей и получения обратной связи от пользователей.
64
Библиографический список
1 Гражданский кодекс Российской Федерации РФ (часть первая) от
30.11.1994 № 51-ФЗ (ред. от 08.12.2020) // Собрание законодательства РФ. –
29.01.1996 - № 5. – ст. 319.
2 Кодекс Российской Федерации об административных правонарушениях
от 30.12.2001 № 195-ФЗ (ред. от 02.08.2019) // Собрание законодательства РФ. –
07.01.2002. – № 1. – ст. 14.57.
3 Налоговый кодекс Российской Федерации РФ (часть вторая) от
05.08.2000 № 117-ФЗ (ред. от 29.12.2019) // Собрание законодательства РФ. – №
31. – 03.08.1998. – ст. 333.19.
4 О банках и банковской деятельности : Федеральный закон № 395-1 :
[принят Государственной думой 2 декабря 1990 года]. – Москва : Дом Советов
РСФСР, 2020 – 86 с.
5 О
защите
прав и
законных
интересов
физических
лиц
при
осуществлении деятельности по возврату просроченной задолженности и о
внесении изменений в Федеральный закон «О микрофинансовой деятельности и
микрофинансовых организациях : Федеральный закон № 230-ФЗ : [принят
Государственной думой 21 июня 2016 года : одобрен Советом Федерации 29
июня 2016 года]. – Москва : Кремль, 2020 – 74 с.
6 О микрофинансовой деятельности и микрофинансовых организациях :
Федеральный закон № 151-ФЗ : [принят Государственной думой 18 июня 2010
года : одобрен Советом Федерации 23 июня 2010 года]. – Москва : Кремль, 2019
– 110 с.
7 Приказ Федеральной службы судебных приставов от 30.12.2019 № 551
«Об утверждении Административного регламента Федеральной службы
судебных приставов по осуществлению федерального государственного
контроля (надзора) за деятельностью юридических лиц, осуществляющих
деятельность по возврату просроченной задолженности в качестве основного
65
вида деятельности, включенных в государственный реестр» (Зарегистрировано в
Минюсте РФ 04.02.2020 № 57417)
8 Приказ Федеральной службы судебных приставов от 28.12.2016 № 825
«Об утверждении требований к оборудованию и программному обеспечению
юридического лица, включенного в государственный реестр юридических лиц,
осуществляющих деятельность по возврату просроченной задолженности в
качестве основного вида деятельности» (Зарегистрировано в Минюсте РФ
29.12.2016 № 45027)
9 Автоматизация деятельности коллекторского агентства // ЦМД софт :
[сайт]. – 2020. URL: https://cmdsoft.ru/solutions/avtomatizatsiya-deyatelnostikollektorskogo-agentstva/ (дата обращения: 01.03.2020)
10 База данных // Patches IT Company : [сайт]. – 2020. URL: https://oraclepatches.com/db/3517-база-данных-определение (дата обращения: 15.05.2020)
11 Введение: знакомство с React // React : [сайт]. – 2020. URL: https://ru.
reactjs.org/tutorial/tutorial.html (дата обращения: 20.04.2020)
12 Введение о системе контроля версий // Git : [сайт]. – 2020. URL:
https://git-scm.com/book/ru/v2/Введение-О-системе-контроля-версий
(дата
обращения: 05.05.2020)
13 Взыскание долгов // Энциклопедия Wiki : [сайт]. – 2020. URL: https://ru.
wikipedia.org/wiki/Взыскание_долгов (дата обращения: 26.01.2020)
14 Диаграмма
материалы
:
вариантов
[сайт].
–
использования
2020.
URL:
//
Учебно-методические
https://www.sites.google.com/site/
anisimovkhv/learning/pris/lecture/tema12/tema12_2 (дата обращения: 29.05.2020)
15 Диаграмма классов // Техническая и гуманитарная литература : [сайт].
– 2020. URL:
http://www.telenir.net/uchebniki/samouchitel_uml/p5.php (дата
обращения: 27.06.2020)
16 Диаграмма компонентов UML // Библиотека электронной литературы :
[сайт].
–
2020.
URL:
https://litresp.com/chitat/ru/%D0%9B/leonenkov-
aleksandr/samouchitelj-uml/10 (дата обращения: 19.06.2020)
66
17 Должник // Словарь Академик : [сайт]. – 2020. URL: https://dic.
academic.ru/dic.nsf/fin_enc/13158 (дата обращения: 14.02.2020)
18 Диаграмма развертывания UML // Онлайн школа : [сайт]. – 2020. URL:
(дата
https://planerka.info/item/diagrammy-razvertyvaniya-uml/
обращения:
19.06.2020)
19 Зачем изучать Node.js, или О перспективах бэкенда на JavaScript //
Хекслет : [сайт]. – 2020. URL: https://ru-hexlet-io.turbopages.org/ru.hexlet.io/s/
blog/posts/zachem-izuchat-node-js-ili-o-perspektivah-bekenda-na-javascript
(дата
обращения: 20.04.2020)
20 Коллекторское агентство // Словарь Академик : [сайт]. – 2020. URL:
https://banks.academic.ru/1158/Коллекторское_агентство
(дата
обращения:
19.01.2020)
21 МФС
Коллекшн.
Программа
для
коллекторских
агентств
//
Автоматизация микрофинансирования : [сайт]. – 2020. URL: https://micfinsystem.
ru/products-and-technologies/mfs_kollekshn/ (дата обращения: 01.03.2020)
22 Нотация BPMN 2.0: ключевые элементы и описание // Comindware :
[сайт]. – 2020. URL: https://www.comindware.com/ru/blog-нотация-bpmn-2-0элементы-и-описание/ (дата обращения: 28.03.2020)
23 Нотация
IDEF0
//
Business
Studio
:
[сайт].
–
2020.
URL:
https://www.businessstudio.ru/wiki/docs/v4/doku.php/ru/csdesign/bpmodeling/idef0
(дата обращения: 28.03.2020)
24 Нотация UML 2.0 // Библиотека технической литературы : [сайт]. –
2020. URL: https://www.htbook.ru/kompjutery_i_seti/programmirovanie/uml-2 (дата
обращения: 28.03.2020)
25 Обзор Balsamiq Mockups // Сообщество бизнес и системных
аналитиков : [сайт]. – 2020. URL: http://analyst.by/articles/balsamiq-mockups (дата
обращения: 30.06.2020)
26 Организационная структура коммерческого банка // Учебник по
банковскому делу : [сайт]. – 2020. URL: http://banki-uchebnik.ru/kommercheskie-
67
banki/11-organizatsionnaya-struktura-kommercheskogo-banka
(дата
обращения:
19.01.2020)
27 Основные характеристики СУБД Oracle // Серверы корпоративных баз
данных : [сайт]. – 2020. URL: http://bourabai.ru/dbt/servers/oracle2.htm (дата
обращения: 05.05.2020)
28 Основы языка PL/SQL // Patches IT Company : [сайт]. – 2020. URL:
https://oracle-patches.com/db/sql/3125-основы-языка-pl-sql
(дата
обращения:
18.04.2020)
29 Основы PL SQL: структура, функции, триггеры, переменные, записи //
Онлайн образование : [сайт]. – 2020. URL: https://zen.yandex.ru/media/id/
5bbcbc1ba5bd5400a990e7d9/osnovy-pl-sql-struktura-funkcii-triggery-peremennyezapisi-5e8c34cf82d52277064ce45b (дата обращения: 18.04.2020)
30 Основы JavaScript // HTML Book : [сайт]. – 2020. URL: https://html5book
.ru/osnovy-javascript/ (дата обращения: 15.04.2020)
31 Продукт «Коллекторская система «Контакт» // Luxbase : [сайт]. – 2020.
URL:
http://www.luxbase.ru/index.php?id=sistema-kontakt
(дата
обращения:
14.04.2020)
32 Программное решение для коллекторских агентств, банков, МФО, КПК
и предприятий из сферы ЖКХ // Первый Бит : [сайт]. – 2020. URL: https://omsk.
1cbit.ru/1csoft/bit-upravlenie-zadolzhennostyu/ (дата обращения: 05.03.2020)
33 Программные комплексы // KRDS : [сайт]. – 2020. URL: https://krds.ru
/softwares (дата обращения: 16.05.2020)
34 Программный комплекс «RU-Collector» // KRDS : [сайт]. – 2020. URL:
https://collector.krds.ru/login (дата обращения: 01.11.2020)
35 Рекомендации по информационной безопасности для бизнеса : [сайт].
– 2020. URL: https://habr.com/ru/post/348892/ (дата обращения: 26.05.2020)
36 Розничный бизнес в организационной структуре банка // Банковский
розничный бизнес : [сайт]. – 2020. URL: https://econ.wikireading.ru/427335652
(дата обращения: 19.01.2020)
68
37 Система для работы с просроченной задолженностью FIS Collection //
Финансовые информационные системы : [сайт]. – 2020. URL: https://fisgroup.ru/
products/collection/ (дата обращения: 14.03.2020)
38 Система «WS.Коллекторское агентство» // Программные системы :
[сайт]. – 2020. URL: http://wfsys.ru/project/collector/ (дата обращения: 19.03.2020)
39 Ссудная задолженность // Сервис подбора финансовых услуг : [сайт]. –
2020.
URL:
https://brobank.ru/ssudnaya-zadolzhennost/
(дата
обращения:
25.01.2020)
40 Стадии взыскания долгов 2020 // Группа компаний Орион : [сайт]. –
2020. URL: https://orion-debt.ru/collection (дата обращения: 25.01.2020)
41 Структурные подразделения организаций: виды // FB : [сайт]. – 2020.
URL:
https://fb.ru/article/274925/strukturnyie-podrazdeleniya-organizatsii-vidyi
(дата обращения: 19.01.2020)
42 Структурное подразделение организаций // онлайн-издание Делать
Дело
:
[сайт].
–
2020.
URL:
https://sovetkadrovika.ru/organizaciya-
biznesa/strukturnoe-podrazdelenie-organizatsii.html (дата обращения: 19.01.2020)
43 Теория и практика UML.Диаграмма состояний // Электронная
библиотека стандартов оформления проектной документации : [сайт]. – 2020.
URL: http://www.it-gost.ru/articles/view_articles/97 (дата обращения: 09.06.2020)
44 Что такое протокол HTTPS и как на него перейти // BookFlow : [сайт].
– 2020. URL: https://bookflow.ru/chto-takoe-protokol-https-i-kak-na-nego-perejti/
(дата обращения: 16.05.2020)
45 Back-end разработка // Checkroi : [сайт]. – 2020. URL: https://checkroiru.turbopages.org/checkroi.ru/s/blog/professiya-bekend-razrabotchik/
(дата
обращения: 17.08.2020)
46 DokuWiki // DokuWiki : [сайт]. – 2020. URL: https://www.dokuwiki
.org/ru:dokuwiki (дата обращения: 07.09.2020)
47 Front-end разработка // ГИД по карьере ИТ : [сайт]. – 2020. URL:
http://buduguru.org/profession/46 (дата обращения: 17.08.2020)
69
48 Git: полное руководство // Гуру : [сайт]. – 2020. URL: https://cyberguru
.tech/программирование/git-полное-руководство (дата обращения: 05.05.2020)
49 KRDS.Редактор документации // KRDS WIKI : [сайт]. – 2020. URL:
https://wiki.krds.ru/admin (дата обращения: 01.10.2020)
50 Markdown // Inter-Net Pro : [сайт]. – 2020. URL: https://inter-net.pro/obovsjom/markdown (дата обращения: 07.09.2020)
51 Node.js // Node : [сайт]. – 2020. URL: https://nodejs.org/ru/about/ (дата
обращения: 18.04.2020)
52 Oracle SQL Developer // Oracle : [сайт]. – 2020. URL: https://www.
oracle.com/database/technologies/appdev/sqldeveloper-landing.html
(дата
обращения: 18.04.2020)
53 PL/SQL // Allround automations : [сайт]. – 2020. URL: https://www.
allroundautomations.com/products/pl-sql-developer/ (дата обращения: 18.04.2020)
54 UML: проектирование программного обеспечения // Habr : [сайт]. –
2020. URL: https://habr.com/ru/post/74330/ (дата обращения: 19.06.2020)
55 WebSockets – Краткое руководство // Coder Lessons : [сайт]. – 2020.
URL:
https://coderlessons.com/tutorials/veb-razrabotka/izuchite-veb-sokety
/websockets-kratkoe-rukovodstvo (дата обращения: 16.05.2020)
56 WebStorm // JET BRAINS : [сайт]. – 2020. URL: https://www.jetbrains.
com/ru-ru/webstorm/ (дата обращения: 25.04.2020)
70
Приложение А
Техническая и программная модели предметной области AS-IS
Таблица А.1 – Техническая модель предметной области
Техническое оборудование
Обобщенное количество единиц
по объектам автоматизации
1. Компьютеры
1) Персональные компьютеры
2) Компьютеры-серверы
2. Периферийные устройства
1) Периферийные устройства телефонии
2) МФУ
3) Факс
3. Телекоммуникационные устройства
1) Аудио устройства – гарнитуры-наушники с
микрофоном (в случае использования облачной
телефонии)
2) Телефонные аппараты (в случае использования
стандартных телефонных сетей)
3) Точка доступа сети Интернет
4. Серверная техника
1) Сервер баз данных
2) Сервер 1С
3) Сервер контроля домена
4) Прокси-сервер
5) Сервер приложений
3 – 526
1 – 12
3 – 218
1 – 22
1 – 15
2 – 526
1 – 307
1 – 52
1 - 52
1 - 11
1–3
1–3
1–3
Таблица А.2 – Базовое и прикладное программное обеспечение AS-IS
Вид
Наименование
1. Базовое программное обеспечение
Операционные системы
– Microsoft Windows 7
– Microsoft Windows 10
– Microsoft Windows 10 PRO
Антивирусные программы
– Kaspersky Total Security
– ESET NOD32 Smart Security
– Dr.Web
– Avast Premium Security/Ultimate
2. Прикладное программное обеспечение
Офисные пакеты
– Microsoft Office 2010
– Microsoft Office 2010 PRO
– Microsoft 365 PRO
Системы архивации
– WinRAR
– 7-Zip
Веб-браузеры
– Yandex Browser
– Google Chrome
– Microsoft Edge
71
Продолжение таблицы 5
Вид
Наименование
2. Прикладное программное обеспечение
Прикладные пакеты
– Собственная разработка на базе MS Office (MS
Excel, MS Acсess)
– Собственная разработка коробочного или облачного
типа
– МФС «Коллекшн» на базе платформы
1С:Предприятие.
– «Моя МФО» на базе платформы 1С:Предприятие.
– «WS.Коллекторское агентство»
Информационно-справочные
– Правовая система «Консультант Плюс»
системы
– Информационно-правовой портал «Гарант»
Системы облачной телефонии
– Ростелеков
(IP-телефония)
– Билайн
– Mango Office
– Дом.ру
Системы смс-рассылок
– SMSRU
(sms-центры)
– Ростелеком
– Билайн
– Дом.ру
– Stream Telecom
Системы автоматизированной
– Наличие систем печати обуславливается наличием
печати документов
устройств МФУ и факса.
72
Приложение Б
Описание бизнес-процесса «Взаимодействие с должником в рамках
возврата просроченных задолженностей» AS-IS
Таблица Б.1 – Описание бизнес-процесса AS-IS «Взаимодействие с
должником в рамках возврата просроченных задолженностей»
Наименование операции,
исполнитель, сроки
01. Анализ текущих задач и их
распределение по сотрудникам
Входы, выходы, требования
Входы:
01.Необходимо определить план задач по каждому
сотруднику – событие.
Исполнитель:
Выходы:
Руководитель коллекторского
01.План задач – электронный документ.
направления
Требования:
01. Руководитель коллекторского направления
Сроки:
Ежедневно, в зависимости от
формирует общий план задач с помощью MS Excel
возникновения новых задач
и рассылает его по электронной почте.
02. Получение, поиск и
Входы:
01.План задач – электронный документ.
ознакомление с собственными
задачами
Выходы:
01.Поиск в документе собственных задач –
событие.
Исполнитель:
Специалист коллекторского
03.Ознакомление с задачами – событие.
направления
Требования:
01. Специалист коллекторского направления
Сроки:
По мере поступления новых задач
получает общий план задач, ищет назначенные на
от руководителя
себя задачи, знакомится с ними.
03. Планирование стратегии
Условия:
01.Должник не внес обещанный платеж – событие.
взаимодействия с должниками
Входы:
01.Ознакомление с задачами – событие.
Исполнитель:
Специалист коллекторского
Выходы:
направления
01.План мероприятий сформирован – событие.
Сроки:
Требования:
После ознакомления с собственными 01. Специалист коллекторского направления
задачами
планирует взаимодействие со всеми должниками на
основе ограничений ФЗ № 230-ФЗ.
04. Взятие в работу задачи
Условия:
01.Имеются активные задачи – событие.
Исполнитель:
Входы:
Специалист коллекторского
01. План мероприятий сформирован - событие.
направления
Выходы:
01.Исполнение мероприятий начато - событие.
Сроки:
Ежедневно, по наступлению даты и Требования:
времени исполнения мероприятия
01. Специалист коллекторского направления
исполняет мероприятия посредством различных
видов взаимодействия с должниками.
73
Продолжение таблицы Б.1
Наименование операции,
исполнитель, сроки
05. Взаимодействие с должниками
в рамках выстроенной стратегии
Исполнитель:
Специалист коллекторского
направления
Сроки:
В процессе исполнения стратегии
взыскания
06. Взаимодействие с
коллекторами
Исполнитель:
Должник
Сроки:
После исполнения взаимодействия
07. Фиксация результатов
первичного взаимодействия
Исполнитель:
Специалист коллекторского
направления
Сроки:
В процессе взаимодействия с
должником или после окончания
взаимодействия
08. Проверка погашения
просроченной задолженности
Исполнитель:
Специалист коллекторского
направления
Сроки:
В процессе взаимодействия с
должником или после окончания
взаимодействия
Входы, выходы, требования
Условие:
01.Неуспешное взаимодействие с должником –
событие.
Входы:
01. План мероприятий сформирован - событие.
Выходы:
01.Взаимодействие с должниками осуществлено –
событие.
Требования:
01. Специалист коллекторского направления
исполняет мероприятия посредством различных
видов взаимодействия с должниками.
Входы:
01.Имеются просроченные задолженности событие.
Выходы:
01. Взаимодействие с коллекторами осуществлено –
событие;
Требования:
01. Заемщик взаимодействует со специалистом
коллекторского направления в рамках возникшей у
него просроченной задолженности.
Входы:
01. Взаимодействие с должниками осуществлено –
событие.
Выходы:
01.Результаты зафиксированы – событие.
Требования:
01. Специалист коллекторского направления
фиксирует результаты взаимодействия с
должниками по вопросам возврата просроченных
задолженностей.
Условие:
01.Успешное взаимодействие с должником –
событие.
Входы:
01.Результаты зафиксированы – событие.
Выходы:
01.Проверка погашения выполнена – событие.
Требования:
01. Специалист коллекторского направления
проверяет фактическое гашение задолженностей
должником в обещанный им период.
74
Окончание таблицы Б.1
Наименование операции,
исполнитель, сроки
09. Закрытие задачи
Исполнитель:
Специалист коллекторского
направления
Сроки:
После полного возврата
задолженности должником или по
истечении работы с ним
10. Проверка задач и отправка
отчета по почте
Исполнитель:
Специалист коллекторского
направления
Сроки:
После исполнения своего плана
работ
11. Мониторинг рабочей
деятельности
Исполнитель:
Руководитель коллекторского
направления
Сроки:
В процессе взаимодействия с
должниками
12. Ознакомление с отчетами и
подведение результатов
Исполнитель:
Руководитель коллекторского
направления
Сроки:
После исполнения задач
сотрудниками
Входы, выходы, требования
Входы:
01.Проверка погашения выполнена – событие.
Выходы:
01.План задач (исправленный) – электронный
документ.
Требования:
01. Специалист коллекторского направления
отмечает исполнение задачи в ИС.
Условие:
01.Все активные задачи выполнены – событие.
Входы:
01.План задач (исправленный) – электронный
документ.
Выходы:
01.План задач (итоговый) – электронный документ.
Требования:
01. Специалист коллекторского направления
проверяет исполненные задачи и отправляет их по
e-mail руководителю.
Входы:
01.Исполнение обязанностей специалистами –
событие.
Выходы:
01.Мониторинг выполнен – событие.
Требования:
01. Руководитель коллекторского направления
выполняет мониторинг рабочей деятельности
специалистов коллекторского направления.
Входы:
01. План задач (итоговый) – электронный документ.
Выходы:
01.Ознакомпление с исполненными задачами –
событие.
Требования:
01. Руководитель коллекторского направления
получает от специалиста план задач и знакомится с
выполненными им задачами и полученными
результатами.
75
Приложение В
Анализ функциональных особенностей информационных систем
Таблица В.1 – Анализ возможностей ИС-аналогов
предметной области
76
77
Продолжение таблицы В.1
Приложение Г
Техническая и программная модели предметной области TO-BE
Таблица Г.1 – Техническая модель предметной области
Техническое оборудование
1. Компьютеры
Персональные компьютеры
Количество единиц
По количеству конечных
пользователей
2. Периферийные устройства
Периферийные устройства телефонии
По количеству конечных
пользователей
По количеству конечных
пользователей и исходя из
нагрузки
МФУ
3. Телекоммуникационные устройства
Аудио устройства – гарнитуры-наушники с
микрофоном (в случае использования облачной
телефонии)
Телефонные аппараты (в случае использования
стандартных телефонных сетей)
Точка доступа сети Интернет
По количеству конечных
пользователей
1 и более (исходя из количества
компьютеров)
Таблица Г.2 – Базовое и прикладное программное обеспечение TO-BE
Вид
Наименование
1. Базовое программное обеспечение
Операционные системы
– Microsoft Windows 7
– Microsoft Windows 10
– Microsoft Windows 10 PRO
Антивирусные программы
– Kaspersky Total Security
– ESET NOD32 Smart Security
– Dr.Web
– Avast Premium Security/Ultimate
2. Прикладное программное обеспечение
Офисные пакеты
– Microsoft Office 2010
– Microsoft Office 2010 PRO
– Microsoft 365 PRO
Веб-браузеры
– Yandex Browser
– Google Chrome
– Microsoft Edge
79
Приложение Д
Описание бизнес-процесса «Взаимодействие с должником в рамках
возврата просроченных задолженностей» TO-BE
Таблица Д.1 – Описание бизнес-процесса «Взаимодействие с должником в
рамках возврата просроченных задолженностей» TO-BE
Наименование операции,
исполнитель, сроки
01 Формирование портфеля требований
и его передача
Исполнитель:
Кредитный отдел
Сроки:
По факту возникновения просроченных
задолженностей у заемщиков
02 Авторизация в программном
комплексе
Исполнитель:
Отделы по возврату просроченных
задолженностей
Сроки:
Ежедневно при исполнении должностных
обязанностей
03 Внесение требований
Исполнитель:
Отделы по возврату просроченных
задолженностей
Сроки:
После получения данных о должниках от
кредитного отдела
Входы, выходы, требования
Входы:
01.Возникновение просроченных
задолженностей у заемщиков – событие.
Выходы:
01.Портфель требований – электронный
и/или печатный документ;
02.Передача портфеля требований отделу по
возврату просроченных задолженностей –
событие.
Требования:
01.Кредитный отдел формирует портфель
требований по просроченным
задолженностям.
Входы:
01. Необходимость работы с должниками и
их задолженностями – событие.
Выходы:
01.Авторизация прошла успешна –событие.
Требования:
01. Отделы по возврату просроченных
задолженностей авторизуется в ПК «RUCollector».
Входы:
01. Портфель требований – электронный
и/или печатный документ.
Выходы:
01.Портфели требований и требования
внесены в ПК – событие.
Требования:
01. Отделы по возврату просроченных
задолженностей вносит данные по
должникам и их требованиям в ПК «RUCollector».
80
Продолжение таблицы Д.1
Наименование операции,
исполнитель, сроки
04 Проверка должников
Входы, выходы, требования
Условие:
01.Необходимо проверить должников по
государственным реестрам – событие.
Исполнитель:
Отделы по возврату просроченных
Входы:
задолженностей
01.Портфели требований и требования
внесены в ПК – событие.
Сроки:
Выходы:
После внесения требований в
01.Проверки должников выполнены –
программный комплекс, при
событие.
необходимости проверки должников в
Требования:
государственных реестрах РФ
01. Отделы по возврату просроченных
задолженностей воспроизводит проверки
должников по различным гос. реестрам РФ
в ПК «RU-Collector».
05 Движение денежных средств
Условие:
01.Необходимо зарегистрировать факт
изменения задолженностей – событие.
Исполнитель:
Отделы по возврату просроченных
Входы:
задолженностей
01.Портфели требований и требования
внесены в ПК – событие.
Сроки:
Выходы:
При необходимости работы с
01.Работа с задолженностями выполнена –
задолженностями и регистрации
событие.
фактических операций по ним
Требования:
01. Отделы по возврату просроченных
задолженностей фиксируют фактические
операции с задолженностями должников в
ПК «RU-Collector».
06 Выстраивание стратегии взыскания
Условие:
01.Необходимо определить
последовательность взаимодействия с
Исполнитель:
Отделы по возврату просроченных
должником – событие.
задолженностей
Входы:
01.Портфели требований и требования
внесены в ПК – событие.
Сроки:
После внесения требований, перед началом Выходы:
взаимодействия с должником
01.Стратегия выстроена –событие.
Требования:
01. Отделы по возврату просроченных
задолженностей определяют поэтапное
взаимодействие в разрезе каждого должника
в ПК «RU-Collector».
81
Продолжение таблицы Д.1
Наименование операции,
исполнитель, сроки
07 Перераспределение мероприятий
Исполнитель:
Отделы по возврату просроченных
задолженностей
Сроки:
При необходимости изменения плана
работ
08 Управление планом работ
Исполнитель:
Отделы по возврату просроченных
задолженностей
Сроки:
В процессе контроля рабочей
деятельности
09 Исполнение мероприятий
Исполнитель:
Отделы по возврату просроченных
задолженностей
Сроки:
В процессе взаимодействия с должниками
в рамках возврата просроченных
задолженностей
10 Подведение итогов работ по
портфелю требований
Исполнитель:
Отделы по возврату просроченных
задолженностей
Сроки:
По завершению работ с портфелем
требований
Входы, выходы, требования
Входы:
01.Стратегия выстроена –событие.
Выходы:
01.Мероприятия перераспределены –
событие.
Требования:
01. Отделы по возврату просроченных
задолженностей при необходимости
выполняют перераспределение мероприятий
в ПК «RU-Collector» исходя из различных
параметров.
Входы:
01.Стратегия выстроена –событие.
Выходы:
01.Успешная работа с планом работ –
событие.
Требования:
01. Отделы по возврату просроченных
задолженностей работает с планом работ в
ПК «RU-Collector».
Входы:
01.Стратегия выстроена –событие.
Выходы:
01.Мероприятие исполнено (успешно
/неуспешно /перенесено) –событие;
02.Карточка исполненного мероприятия –
электронный документ.
Требования:
01. Отделы по возврату просроченных
задолженностей исполняет взаимодействие
с должником соответствующим
исполняемому мероприятию способом и
регистрирует результаты в ПК «RUCollector».
Входы:
01.Исполнены все варианты взаимодействия
с должником – событие.
Выходы:
01.Отчетность по результатам
взаимодействия – электронный и/или
бумажный документ.
Требования:
01. Отделы по возврату просроченных
задолженностей формируют сводную
отчетность по работе с должниками и
полученным результатам в ПК «RUCollector».
82
Окончание таблицы Д.1
Наименование операции,
исполнитель, сроки
11 Ознакомление с результатами работ
по портфелю
Исполнитель:
Кредитный отдел
Сроки:
После завершения взаимодействия с
должниками и получения отчетных
результатов
Входы, выходы, требования
Входы:
01.Отчетность по результатам
взаимодействия – электронный и/или
бумажный документ.
Выходы:
01.Знакомвство с результатами
взаимодействия – событие.
Требования:
01. Кредитный отдел анализирует сводную
отчетность по результатам взаимодействия с
должниками и принимает решение о
последующих методах возврата
просроченных задолженностей.
83
Приложение Е
Архитектура баз данных
программного комплекса
«RU-Collector»
Рисунок Е.1 – Архитектура базы данных программного комплекса «RU-Collector»
84
Приложение Ж
Прототипы интерфейсов программного комплекса «RU-Collector»
Рисунок Ж.1 – Интерфейс неуспешной авторизации пользователя
Рисунок Ж.2 – Интерфейс восстановления пароля пользователя
85
Рисунок Ж.3 – Интерфейс неуспешного восстановления пароля
Рисунок Ж.4 – Интерфейс «Главная» (редактирование данных)
86
Рисунок Ж.5 – Интерфейс «Главная» (сохранение редактирования денных)
Рисунок Ж.6 – Интерфейс «Главная» (изменение пароля)
87
Рисунок Ж.7 – Интерфейс «Главная» (сохранение изменения пароля)
Рисунок Ж.8 – Интерфейс «Внесение требований»
(внесение общей информации по портфелю
88
Рисунок Ж.9 – Интерфейс «Внесение требований»
(выбор мероприятий по портфелю)
Рисунок Ж.10 – Интерфейс «Внесение требований»
(единичное внесение требований)
89
Рисунок Ж.11 – Интерфейс «Внесение требований»
(массовое внесение требований через Excel)
Рисунок Ж.12 – Интерфейс «Внесение требований»
(сохранение некорректного требования)
90
Рисунок Ж.13 – Интерфейс «Внесение требований»
(сохранение портфеля и требований)
Рисунок Ж.14 – Интерфейс «Внесение требований» (корректировка данных)
91
Рисунок Ж.15 – Интерфейс «Выстраивание стратегии по требованию»
(выбор параметров стратегии)
Рисунок Ж.16 – Интерфейс «Выстраивание стратегии по требованию»
(просмотр проведенных мероприятий)
92
Рисунок Ж.17 – Интерфейс «Выстраивание стратегии по требованию»
(сохранение стратегии на требовании)
Рисунок Ж.18 – Интерфейс «Выстраивание стратегии по портфелю»
(выбор стратегии)
93
Рисунок Ж.19 – Интерфейс «Выстраивание стратегии по портфелю»
(просмотр проведенных мероприятий)
Рисунок Ж.20 – Интерфейс «Выстраивание стратегии по портфелю»
(сохранение стратегии на портфеле)
94
Рисунок Ж.21 – Интерфейс «Исполнение мероприятий»
(фактическое исполнение мероприятия)
Рисунок Ж.22 – Интерфейс «Исполнение мероприятий» (исполнение)
95
Рисунок Ж.23 – Интерфейс «Исполнение мероприятий» (перенос)
Рисунок Ж.24 – Интерфейс «Исполнение мероприятий»
96
Рисунок Ж.25 – Интерфейс «План работ»
(календарь подразделения на определенный день)
Рисунок Ж.26 – Интерфейс «План работ»
(календарь подразделения на определенный день в разрезе исполнителя)
97
Рисунок Ж.27 – Интерфейс «План работ»
(параметры перераспределения мероприятий)
Рисунок Ж.28 – Интерфейс «План работ»
(подтверждение перераспределения мероприятий)
98
Рисунок Ж.29 – Интерфейс «План работ»
(результат перераспределения мероприятий)
Рисунок Ж.30 – Интерфейс «Движение денежных средств»
(информация в разрезе определенного требования)
99
Рисунок Ж.31 – Интерфейс «Движение денежных средств»
(добавление нового платежа)
Рисунок Ж.32 – Интерфейс «Движение денежных средств»
(результат добавления нового платежа)
100
Рисунок Ж.33 – Интерфейс «Техподдержка» (массив обращений)
Рисунок Ж.34 – Интерфейс «Техподдержка» (диалог обращения)
101
Рисунок Ж.35 – Интерфейс «Техподдержка» (закрытие обращения)
Рисунок Ж.36 – Интерфейс «Уведомления»
102
103
(функционал создания портфеля и требований)
Рисунок И.1 – Листинг front-кода программного решения «Внесение требований»
Приложение И
Листинг кода программного комплекса «RU-Collector»
104
(функционал создания портфеля и требований)
Рисунок И.2 – Листинг back-кода программного решения «Внесение требований»
105
(функционал выстраивания стратегии взыскания на требовании)
Рисунок И.3 – Листинг front-кода программного решения «Выстраивание стратегии»
106
(реализация общих правил выстраивания стратегии взыскания)
Рисунок И.4 – Листинг back-кода программного решения «Выстраивание стратегии»
107
(реализация реквизитного состава в карточке исполнения мероприятия)
Рисунок И.5 – Листинг front-кода программного решения «Исполнение мероприятий»
108
(реализация общего функционала ограничений на исполнение мероприятий)
Рисунок И.6 – Листинг back-кода программного решения «Исполнение мероприятий»
109
(функционал распределения мероприятий по исполнителям)
Рисунок И.7 – Листинг front-кода программного решения «План работ»
110
(функционал распределения мероприятий по исполнителям)
Рисунок И.8 – Листинг back-кода программного решения «План работ»
111
(реализация функционала по созданию нового платежа в разрезе определенного требования)
Рисунок И.9 – Листинг front-кода программного решения «Движение денежных средств»
112
(реализация функционала по созданию нового платежа в разрезе определенного требования)
Рисунок И.10 – Листинг back-кода программного решения «Движение денежных средств»
Рисунок К.1 – Реализация пользовательской документации (интерфейс «Авторизация»)
Приложение К
Пользовательская документация программного комплекса «RU-Collector»
113
114
(программное решение «Внесение требований»)
Рисунок К.2 – Реализация пользовательской документации
115
(программное решение «Выстраивание стратегии»)
Рисунок К.3 – Реализация пользовательской документации
116
(программное решение «Исполнение мероприятий»)
Рисунок К.4 – Реализация пользовательской документации
117
(программное решение «План работ»)
Рисунок К.5 – Реализация пользовательской документации
118
(программное решение «Движение денежных средств»)
Рисунок К.6 – Реализация пользовательской документации
119
Рисунок К.7 – Вид пользовательской документации (интерфейс «Авторизация»)
120
(программное решение «Внесение требований»)
Рисунок К.8 – Вид пользовательской документации
121
(программное решение «Выстраивание стратегии»)
Рисунок К.9 – Вид пользовательской документации
122
(программное решение «Исполнение мероприятий»)
Рисунок К.10 – Вид пользовательской документации
123
(программное решение «План работы»)
Рисунок К.11 – Вид пользовательской документации
124
(программное решение «Движение денежных средств»)
Рисунок К.12 – Вид пользовательской документации
Отзывы:
Авторизуйтесь, чтобы оставить отзыв