Проектирование реализации операций бизнес-процесса «Ведение договоров по страхованию автотранспортных средств (Характеристика таблиц с результативной информацией)

Содержание:

ВВЕДЕНИЕ

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

Существует несколько видов автомобильного страхования. Договор автомобильного страхования «ОСАГО» является обязательным. Этот договор заключают со страховой компанией все владельцы автомобилей. Также существует расширенное страхование автомобилей – «КАСКО».

Договор автомобильного страхования «КАСКО» отличается от «ОСАГО» большей стоимостью и имеет ряд преимуществ:

• Страхование автомобиля от угона;
• Страхование от повреждений;
• Возмещение ущерба случае ДТП.

В некоторых случаях договор «КАСКО» является обязательным. Например, когда автомобиль приобретается в кредит.

Несмотря на перечисленные факторы, рынок автострахования еще не является совершенным ввиду своей молодости. К недостаткам рынка страхования относятся:

• часто меняющиеся тарифы на услуги страхования;
• законодательство в сфере страхования.

В процессе оформления договора страхования осуществляется большой сбор данных о водителе и транспортном средстве. Эти данные учитываются в договоре страхования и хранятся в страховой компании.

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

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

Объектом исследования является бизнес-процесс ведения договоров по страхованию автотранспортных средств.

Предметом исследования является автоматизация процесса ведения договоров по страхованию автотранспортных средств.

Целью работы является проектирование реализации операций бизнес-процесса ведения договоров по страхованию автотранспортных средств.

Для достижения поставленной цели необходимо решить ряд задач:

1. Выбрать комплекс задач автоматизации.
2. Охарактеризовать существующие бизнес-процессы.
3. Описать документооборот, возникающий при решении задачи.
4. Обосновать проектные решения по информационному обеспечению.
5. Дать обоснование проектным решениям по программному обеспечению.
6. Создать и описать информационную модель.
7. Дать характеристику нормативно-справочной, входной и оперативной информации.
8. Охарактеризовать результативную информацию.
9. Разработать общие положения.
10. Дать характеристику базе данных.
11. Разработать структурную схему пакета.
12. Описать программные модули.
13. Разработать контрольный пример реализации.
14. Аналитическая часть
15. Выбор комплекса задач автоматизации

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

Входными информационными потоками процесса являются:

1. Данные водителя – паспортные данные и данные из водительских прав.
2. Данные транспортного средства – данные из паспорта транспортного средства (ПТС).

Выходным информационным потоком процесса является договор автострахования.

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

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

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

В процессе ведения договоров задействованы следующие специалисты:

1. Специалист по страхованию, который осуществляет сбор и формирование документооборота процесс.
2. Специалист по андеррайтингу, который осуществляет принятие решений по договору страхования и оценку рисков по каждому договору.

Основными понятиями и определениями предметной области являются [5]:

1. Андеррайтинг – процесс оценки страховых рисков.
2. Договор автострахования – документ, в котором перечислены условия страхования транспортного средства.
3. Страховая сумма – сумма денежных средств, определенная договором страхования, в пределах которой страховая организация несет ответственность по договору страхования.
4. Страховая премия – плата за страхование, которую страхователь обязан заплатить страховой организации в порядке и в сроки, установленные договором страхования.
5. Страховая выплата – это сумма денежных средств, установленная договором страхования, выплачиваемая страховой организацией при наступлении страхового случая в виде единовременной выплаты в размере, указанном в договоре страхования.

Входными документами будут являться:

1. Паспорт страхователя.
2. Водительское удостоверение.
3. Паспорт транспортного средства.

Выходным документом будет являться договор страхования.

1. Характеристика существующих бизнес – процессов

Рассмотрим бизнес-процесс ведения договоров автострахования. На рисунке 1 представлена контекстная диаграмма бизнес-процесса ведения договоров автострахования. Управление бизнес-процессом осуществляется согласно законодательству РФ и внутренним регламентам бизнес-процесса. Механизмами бизнес-процесса являются специалист по страхованию и специалист по андеррайтингу. Входными потоками процесса являются ПТС, паспорт и водительское удостоверение страхователя. Выходными потоком является договор автострахования.

Рисунок 1. Контекстная диаграмма бизнес-процесса

Рисунок 2. Декомпозиция бизнес-процесса

На рисунке 2 представлена декомпозиция бизнес-процесса. Сначала специалистом по страхованию осуществляется проверка транспортного средства. Результаты проверки передаются специалисту по андеррайтингу, который на основании полученных данных осуществляет оценку рисков. По результату оценки рисков принимается решение о возможности заключения договора страхования и сумме страхования. Если принято положительное решение о заключении договора в результате оценки рисков, специалист по страхованию заключает договор с клиентом.

1. Характеристика документооборота, возникающего при решении задачи

Рассмотрим документооборот задачи. В процессе решения задачи формируются следующие документы:

1. Протокол проверки транспортного средства.
2. Протокол оценки рисков.
3. Договор автострахования.

Создадим схему документооборота задачи, основанную на перечисленных документах. Схема документооборота представлена на рисунке 3.

Рисунок 3. Схема документооборота процесса

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

Таблица 1

Характеристика формирования документооборота

Характеристика	Протокол проверки	Протокол оценки рисков	Договор автострахования
Количество документов в год, шт.	200 000	200 000	200 000
Количество символов в документе, шт.	5 000	5 000	50 000
Частота возникновения в год	1	1	1
Трудозатраты на обработку в год, чел-час	80 000	80 000	30 000

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

1. Высокие временные затраты на формирование документооборота.
2. Низкий уровень оперативности данных о транспортных средствах.
3. Несовершенство организации сбора и регистрации исходной информации.

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

Таблица 2

Характеристика формирования документооборота после автоматизации

Характеристика	Протокол проверки	Протокол оценки рисков	Договор автострахования
Количество документов в год, шт.	200 000	200 000	200 000
Количество символов в документе, шт.	5 000	5 000	50 000
Частота возникновения в год	1	1	1
Трудозатраты на обработку в год, чел-час	40 000	40 000	10 000

Трудозатраты на формирование документооборота до автоматизации составляют 190 000 человеко-часов. Трудозатраты на формирование документооборота после автоматизации составят 90 000 человеко-часов. Т.о. планируемое снижение трудозатрат составит 53%.

1. Обоснование проектных решений по информационному обеспечению

Рассмотрим состав и содержание входных документов. Входными документами задачи являются:

1. Паспорт страхователя.
2. Водительское удостоверение страхователя.
3. Паспорт транспортного средства.

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

Выходным документом является договор автострахования, который имеет унифицированную форму, поэтому оригинальное проектирование также не потребуется. Документ должен иметь возможность печати и сохранения в форматах: .doc, .docx, .xlsx, .xls для обеспечения удобства дальнейшей обработки.

В проектируемой системе будет использован один международный классификатор – денежная единица.

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

1. Обоснование проектных решений по программному обеспечению

Информационные системы позволяют пользователям осуществлять сбор и обработку данных. Для хранения данных используются базы данных. Различают следующие виды баз данных:

1. Иерархические.
2. Сетевые.
3. Реляционные.

В настоящее время широко применяются реляционные базы данных в связи со следующими факторами:

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

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

• Microsoft SQL Server;
• IBM DB2;
• Oracle database.

СУБД IBM DB2 является кросс-платформенной, обеспечивает стабильную работу базы данных. Недостатками системы являются высокая стоимость и низкая производительность. СУБД Microsoft SQL Server обладает большим пакетом инструментов, стабильностью работы и низкими затратами на администрирование. Недостаток системы заключается в том, что она работает только на платформе Windows. СУБД Oracle обладает высокой производительностью, легкостью интегрирования приложений и устойчивостью к большим потокам данных. Недостатком является высокая стоимость, необходимость приобретения мощного оборудования и персонала для поддержки СУБД. Ввиду перечисленных свойств реляционных СУБД был сделан выбор в пользу СУБД Oracle [1].

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

В качестве языка программирования был выбран язык программирования С++, который обладает следующими преимуществами:

• большей безопасностью по сравнению с другими языками;
• возможностью писать обобщенный код с помощью шаблонов;
• возможностью использования объектно-ориентированного подхода;
• управления ресурсами с помощью RAII;
• упрощение программного кода за счет перегрузки функций и операторов;
• более простой обработки ошибок за счет исключений [10].

Рассмотрим существующие среды программирования, которые поддерживают язык программирования c++. Среда программирования «Visual Studio 2015» является одной из старейших продуктов для создания программных продуктов с графическим интерфейсом. Возможность добавления сторонних плагинов способствует расширению функциональности среды программирования до кроссплатформенного состояния. К недостатком этой среды можно отнести то, что разработчик должен обладать опытом создания приложений, для работы с этой средой.

Среда программирования «IntelliJ IDEA» позволяет осуществить разработку программных продуктов на множестве популярных языков программирования. Но у системы существует существенный недостаток производительности в процессе компиляции, перекомпиляции и тестирования.

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

Мощной платформой для разработки приложений, которая позволяет создавать приложения на языке программирования с++, является платформа «Netbeans». Однако, платформа обладает низким показателем быстродействия и ограничением функциональности некоторых плагинов [8].

На основании рассмотренных сред программирования, поддерживающих язык с++, был сделан вывод о том, что наиболее надежной средой программирования будет являться среда «MS Visual Studio».

Для создания отчетных форм будет использован программный продукт «DesignFR», которое позволяет просматривать и редактировать файлы отчетов.

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

1. Проектная часть

2. Информационная модель и её описание

Информационная модель представляет собой схему, отражающую преобразование информационных реквизитов от источников информации до её получателей или, иными словами, процесс обработки информации в информационной системе [2]. Рассмотрим информационную модель предметной области. Информационная модель представлена на рисунке 5.

Рисунок 5. Информационная модель

1. Характеристика нормативно-справочной, входной и оперативной информации

Входными документами являются:

1. Паспорт страхователя, который содержит данные о страхователе, номере и серии документа, дате выдачи и органе выдачи документа.
2. Водительское удостоверение, который содержит данные о страхователе, номере и серии документа, дате выдачи и органе выдачи документа.
3. Паспорт транспортного средства, который содержит информацию об автомобиле (рисунок 6).

Рисунок 6. Паспорт транспортного средства

Перечисленные документы поступают от страхователей и содержат следующие показатели:

1. ФИО страхователя.
2. Дата рождения.
3. Место рождения.
4. Серия и номер документа.
5. Дата выдачи документа.
6. Орган выдачи документа.
7. Срок действия документа.
8. Наименование транспортного средства.
9. Марка и модель транспортного средства.
10. Дата регистрации.

Каждый документ содержит от 30 до 300 строк, объем документов составляет до 50 000 символов. Частота возникновения документа до 100 ежедневно.

В проектируемой информационной системе должны присутствовать следующие справочники:

1. Сотрудник.
2. Клиент.
3. Денежная единица.
4. Вид страхования.

Характеристика справочников представлена в таблице 3.

Таблица 3

Характеристика справочников

Характеристика	Клиент	Сотрудник	Денежная единица	Вид страхования
Ответственный за ведение	Специалист по страхованию	Руководитель отдела страхования
Объем справочника в записях	10 000	100	10	2
Частота актуализации	Ежедневно	По мере необходимости (минимум – раз в квартал)
Объем актуализации	5%
Реквизитный состав	Фамилия	Фамилия	Код	Код
	Имя	Имя	Наименование	Наименование
	Отчество	Отчество
	Дата рождения	Должность
	Адрес регистрации
	Документ подтверждающий личность

1. Характеристика результатной информации

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

1. Сотрудник.
2. Клиент.
3. Договор.

Характеристика перечисленных таблиц представлена в таблице 4.

Таблица 4

Характеристика таблиц с результативной информацией

Наименование таблицы	Наименование поля
Сотрудник	Фамилия
	Имя
	Отчество
Клиент	Фамилия
	Имя
	Отчество
Договор	Номер
	Дата
	Сумма

1. Общие положения (дерево функций и сценарий диалога)

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

1. Функции, реализующие служебные функции.
2. Функции, реализующих основные функции управления и обработки данных [9].

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

Разработаем дерево функций системы, согласно приведенным рекомендациям. К основным функциям разрабатываемой системы относятся:

1. Редактирование справочников.
2. Ввод данных.

К служебным функциям разрабатываемой ИС относятся:

1. Формирование отчетов.

Дерево функций представлено на рисунке 7 [7].

Рисунок 7. Дерево функций системы

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

1. Характеристика базы данных

Проектируемая ИС будет хранить и обрабатывать данные в реляционной базе данных, которая представляет собой совокупность двумерных таблиц [6]. База данных будет включать следующие таблицы:

1. Сотрудник.
2. Клиент.
3. Денежная единица.
4. Вид страхования.
5. Протокол проверки.
6. Оценка рисков.
7. Договор.
8. Транспортное средство.

Рисунок 8. Сценарий диалога

Для описания взаимосвязей между таблицами построим ER-модель. ER-модель представлена на рисунке 9.

Рисунок 9. ER-модель

Характеристика таблиц базы данных представлена в таблице 5.

Таблица 5

Характеристика базы данных

Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Справочник «Сотрудник»
ID_сотрудника	ID_epml	Счетчик	5	Ключевое поле
Фамилия	Lname_empl	Текст	30
Имя	Fname_empl	Текст	30
Отчество	Mname_empl	Текст	30
Должность	D_empl	Текст	30
Справочник «Клиент»
ID_клиента	ID_cl	Счетчик	5	Ключевое поле
Фамилия	Lname_cl	Текст	30
Имя	Fname_cl	Текст	30
Отчество	Mname_cl	Текст	30
Дата рождения	BDate_cl	Дата	8
Адрес регистрации	Address_cl	Текст	100
Паспорт	Pass_cl	Текст	300
Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Водительское удостоверение	Lic_cl	Текст	300
Справочник «Денежная единица»
ID_единицы	ID_cur	Счетчик	5	Ключевое поле
Код	Ccur	Число	3
Наименование	Ncur	Текст	30
Справочник «Вид страхования»
ID_вида	ID_str	Счетчик	5	Ключевое поле
Код	Cstr	Число	3
Наименование	Dstr	Текст	30
Протокол проверки
ID_протокола	ID_pr	Счетчик	5	Ключевое поле
Номер	Num_pr	Текст	15
Дата	Date_pr	Дата	8
Описание	Op_pr	Текст	300
Оценка рисков
ID_оценки	ID_ocen	Счетчик	5	Ключевое поле
Номер	Num_ocen	Число	15
Дата	Date_ocen	Дата	8
Описание	Op_ocen	Текст	300
Договор
ID_договора	ID_doc	Счетчик	5	Ключевое поле
Номер	Ndoc	Число	300
Дата заключения	Zdate	Дата	8
Дата окончания	Odate	Дата	8
Сумма	Sum_doc	Число	6
Транспортное средство
ID_средства	ID_ts	Счетчик	5	Ключевое поле
Марка	Ma_ts	Текст	15
Модель	Mo_ts	Текст	15
Год выпуска	G_ts	Число	4
Номер	N_ts	Число	5
№ ПТС	Np_ts	Число	6

1. Структурная схема пакета (дерево вызова программных модулей)

Структурная схема пакета программных модулей состоит из модулей следующих классов:

1. Модули, выполняющие служебные функции.
2. Управляющие модули, осуществляющие загрузку меню и передачу управления другому модулю.
3. Модули, связанные с хранением, обработкой и выдачей информации.

Описание функций модулей позволяет структурировать файлы информационной системы, обеспечить надежность системы и удобство при сопровождении системы [4].

Описание функций модулей представлено в таблице 6.

Таблица 6

Описание функций модулей

№ п/п	Наименование модуля	Функции модуля
1	Глобальный модуль	Содержит глобальные процедуры и функции, предопределенные процедуры, процедуры и функции, которые необходимо выполнить при запуске системы
2	Модуль справочника «Сотрудник»	Содержит предопределенные процедуры формы списка и элементы справочника
3	Модуль справочника «Клиент»	Содержит предопределенные процедуры формы списка и элементы справочника
4	Модуль справочника «Денежная единица»	Содержит предопределенные процедуры формы списка и элементы справочника
5	Модуль справочника «Вид страхования»	Содержит предопределенные процедуры формы списка и элементы справочника
5	Модуль документа	Содержит предопределенные процедуры формы списка и элементы справочника

Модель дерева вызова программных модулей представлено на рисунке 10.

1. Описание программных модулей

На рисунке 11 представлен алгоритм формирования оговора страхования транспортного средства. На основании результатов оценки рисков специалист отдела страхования осуществляет формирование договора автострахования. Формирование документа происходит, если уровень оценки риска больше или равен 3. Иначе формирование документа прекращается.

Рисунок 10. Модель дерева вызова программных модулей

Если уровень оценки риска больше или равен 3, формируется форма договора, в которой специалист по страхованию выбирает из справочников клиента и транспортное средство. Затем формируется форма заполненного договора автострахования, которая доступна для печати. В дальнейшем пользователь может сохранить изменения или закрыть форму договора. В этом случае изменения сохранены не будут.

Рисунок 11. Алгоритм формирования договора автострахования

1. Контрольный пример реализации проекта и его описание

Для разработки контрольного примера реализации проекта и его описания необходимо:

1. Описать тестовые данные, которые необходимы для проверки работоспособности основных функций проекта.
2. Описать процесс обработки тестовых данных.
3. Описать результаты обработки тестовых данных.

Реализация контрольного примера состоит из следующих этапов:

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

На рисунке 12 представлено заполнение справочника «Клиент».

Рисунок 12. Справочник «Клиент»

На рисунке 13 представлен результат ввода данных в справочник «Сотрудник».

Рисунок 13. Справочник «Сотрудник»

На рисунке 14 представлен результат ввода данных о денежных единицах, используемых в системе.

Рисунок 14. Справочник «Денежные единицы»

На рисунке 15 представлен ввод данных о транспортном средстве.

Рисунок 14. Ввод данных о транспортном средстве

На рисунке 16 представлена форма ввода данных о договоре.

Рисунок 16. Форма договора

В результате заполнения документов в информационной системе формируется печатная форма сертификата страхования доступная для печати (рисунок 17).

Рисунок 17. Печатная форма сертификата страхования

ЗАКЛЮЧЕНИЕ

В ходе выполнения курсовой работы было проведено обследование предметной области. Дано описание комплекса задач автоматизации и обоснование их выбора. Были описаны бизнес-процессы предметной области с помощью нотации IDEF0.

Были описаны информационные потоки, возникающие в результате осуществления документооборота, возникающего при ведении договоров автострахования.

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

В ходе анализа существующих проектных решений по программному обеспечению было выбрано оптимальное решение.

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

Были разработаны дерево функций системы и сценарий диалога. Дана характеристика базы данных, разработана ER-модель базы данных, приведённой к третьей нормальной форме.

Разработана структурная схема пакетов программных модулей. Дано описание программных модулей. Разработан контрольный пример реализации системы и его описание.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Гвоздева Т.В., Баллод Б.А. / Проектирование информационных систем. – М.:Феникс, 2014.
2. Горбаченко В.И., Убиенных Г.Ф. / Проектирование информационных систем с СА ErwinModelingSuite 7.3. – П.:ПГУ 2014.
3. Грекул В.М, Коровкина Н.А, Куприянов В.С. / Проектное управление в сфере информационных технологий. – М.:БИНОМ, ИНФРА-М, 2013.
4. ЕлиферовВ.Г., РепинВ.В. / Процессный подход к управлению. Моделирование бизнес-процессов. – М.:Манн, Иванов и Фербер, 2013.
5. Избачков Ю.С., Петров В.Н. / Информационные системы. – СПб,: Амфора. 2014.
6. Исаев Г.Н. / Проектирование информационных систем. Учебное пособие. – М.: Омега-Л, 2015.
7. Мацяшек Л.А. / Проектирование информационных систем. – М.: Вильямс,2016.
8. Ньютон Р. / Управление проектами от А до Я. – М.: Альпина Паблишер, 2014.
9. Смит К.У., Уильямс Л.Дж. / Эффективные решения: практическое руководство по созданию гибкого и масштабируемого программного обеспечения. – М.:Вильямс, 2013.
10. Эванс Э. / Предметно-ориентированное проектирование: структуризация сложных программных систем. – М. Вильямс, 2016.