Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Разработка регламента выполнения процесса «Ведение договоров по страхованию автотранспортных средств» (Виды страхования автотранспортных средств)

Содержание:

ВВЕДЕНИЕ

Темой курсового проектирования является «Разработка регламента выполнения процесса «Ведение договоров по страхованию автотранспортных средств»».

В рамках курсового проектирования ведётся разработка программы для автоматизации учета договоров по страхованию автотранспортных средств в ООО «ДоставимСами».

Тема разработки: «Разработка регламента выполнения процесса «Ведение договоров по страхованию автотранспортных средств»»

Актуальность разработки регламента заключается в следующем:

в настоящий момент регламент работы далек от совершенства, что видно из проведенного исследования предметной области;

регламент помогает избежать ошибок и не точностей при выборе условий страховки и анализа рентабельности страховки;

при использовании нового регламента работы использующего ИС значительно снижается трудоёмкость ведения базы данных договоров автострахования.

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

Проблема исследования состоит в разрешении этого противоречия.

Цель исследования – разработка регламента выполнения процесса «Ведение договоров по страхованию автотранспортных средств».

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

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

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

Уменьшение количества ошибок в страховании ведущих к штрафам

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

Автоматизация составление отчетов для анализа стоимости страховки

Формирование единой базы документов

Отображение истекающих договоров страхования

Сокращение штрафов за несвоевременную страховку

Задачи исследования:

Анализ литературы

Исследование и описание предметной области

Изучение методологий и средств проектирования бизнес-процессов

Моделирование бизнес процесса в настоящий момент

Выявление проблемы малой эффективности бизнес-процесса

Разработка мероприятий по улучшению бизнес-процесса

Моделирование бизнес процесса после проведения мероприятий

Изучение возможностей автоматизации на базе 1С:Предприятие

Разработка ИС для автоматизации бизнес-процесса.

Методологическая база исследования – теория программирования в 1С(Габец А.П, Гончаров Д.И.,Радченко М.Г.), теория информационных систем( Титоранко Г.А.,Дзюбенко.А.Л. Глушков В.М.), теория Case-технологий (Иаклаков С.В)

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

Практическая значимость работы — ИС для учета договоров автострахования транспортных средств, разработанная для ООО «ДоставимСами», позволит повысить точность анализа стоимости автострахования, уменьшить ошибки по страхованию, поможет быстрее получать актуальную информацию о состоянии транспортных средств и договоров страхования.

ГЛАВА 1. ОПИСАНИЕ ПРОЦЕССА СТРАХОВАНИЯ АВТОТРАНСПОРТНЫХ СРЕДСТВ

1.1 Виды страхования автотранспортных средств

В Российской Федерации страхование автотранспортных средств осуществляют через заключение договора имущественного страхования, который составляется в соответствии с требованиями главы 48 "Страхование" ГК РФ, Закона от 27.11.1992 № 4015-1 "Об организации страхового дела в Российской Федерации", Федерального закона от 25.04.2002 № 40-ФЗ "Об обязательном страховании гражданской ответственности владельцев транспортных средств" (далее по тексту - Закон об ОСАГО) и других нормативно-правовых актов.

Договор страхования автотранспортных средств заключается в отношении: транспортного средства (ст. 930 ГК РФ) или риска гражданской ответственности владельцев транспортных средств (ст. 931 и 932 ГК РФ). Форма данного страхования может быть как обязательная, так и добровольная.

Виды полисов:

ОСАГО – обязательное страхование по последствиям причинения вреда жизни, здоровью и имуществу;

КАСКО – добровольное страхование имущества;

ДСАГО – добровольное страхование гражданской ответственности.

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

Право владения транспортным средством возникает в результате:

приобретения его в собственность;

получения хозяйственное ведение;

получение в оперативное управление;

в результате аренды;

доверенности на право управления транспортным средством;

распоряжения соответствующего органа о передаче лицу ТС.

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

Владельцем не является:

лицо, при исполнении служебных обязанностей;

лицо, при исполнении трудовых обязанностей.

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

В законе об ОСАГО содержится 11 исключений выплоты страхового возмещения, например, в случае причинения морального вреда и по возмещению упущенной выгоды и др.

В договоре определяется:

объект обязательного страхования;

страховой случай;

страховую сумму, страховую премию и порядок ее уплаты;

срок действия, порядок заключения, изменения, продления срока действия, досрочного прекращения договора обязательного страхования;

порядок определения размера и осуществления выплаты при причинении вреда потерпевшему;

порядок разрешения споров.

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

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

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

При ДТП страхователь обязуется сообщить всем участникам о договоре обязательного страхования гражданской ответственности.

Лицо, не заключившее договор ОСАГО либо не имеющее при себе во время управления транспортным средством страхового полиса обязательного страхования, может быть привлечено к административной ответственности в виде штрафа[22].

Организация ООО «ДоставимСами» занимается перевозкой грузов на транспортных средствах им принадлежащим. В автомобильном парке учтено 5 автомобилей ГАЗ грузоподъемностью 3 тонны и 2 автомобиля ГАЗ грузоподъемностью 4 тонны. За некоторыми автомобилями закреплены определенные водители работающие посменно, некоторые автомобили используются любым свободным водителем и страхуется договором не предусматривающим перечисления лиц, допущенных до управления.

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

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

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

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

При разработке решения поставленной задачи были определены заинтересованные лица и пользователи разрабатываемой информационной системы[7] (Таблица 1).

Заинтересованные лица

Таблица 1

Представитель

Кожевников Иван Григорьевич Руководитель

Мишутин Олег

Описание

Руководитель

Заведующий автохозяйством

Разработчик

Тип

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

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

Неоконченное высшее образование, знание техники и компьютерных программ на высоком уровне.

Ответственность

Увеличение прибыли организации. Страхование всего автопарка на выгодных условиях.

Своевременное страхование автопарка.

Разработка информационной системы отвечающей требованиям заказчика.

Критерий успеха

Страхование по выгодным условиям. Увеличение количества оплаченных страховых случаев.

Застрахованный автопарк на выгодных условиях

Внедренный сайт

Вовлеченность

Утверждение проекта, тестирование, принятие решений о доработке.

Тестирование, консультирование.

Разработка

Комментарии / Проблемы

Сложность анализа информации о страховых случаях.

Отслеживание сроков договоров страхования и лиц, допущенных к управлению

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

Сокращение затрат на выплаты при ДТП и страховку

Заинтересованные лица

Руководитель

Заведующий автохозяйством

Как достичь цели?

Сократить ущерб от ДТП не оплаченный страховкой

Сократить количество штрафов за несвоевременную страховку

Застраховать автопарк по выгодным условиям

Что будем делать для достижения целей?

Своевременная оплата договоров страхования

Изучить информацию по прошлым страховым случаям

Отслеживание сроков действия договора

Назначение водителей на автомобиль в соответствии со страховкой

Анализ условий страхования

Рисунок 1. Карта воздействий Impact Mapping


1.2 Обзор методологий и средств моделирования бизнес-процессов

Методология IDEF0 взяла за основу технологию структурного анализа и проектирования SAD . Аббревиатура IDEF расшифровывается как ICAM DEFinition и содержит в себе комплекс методологий: IDEF0,IDEF1, IDEFlx, IDEF2, IDEF3 и т.д. В принятых рекомендациях по стандартизации методология IDEF0 названа методологией функционального моделирования.

Основой IDEF0 является моделирование систем на графическом языке. Диаграмма IDEF0 имеет вид именованных блоков, соединенных друг с другом стрелками.

Блоки это функции. Стрелки имеют различное значение, которое зависит от стороны их присоединения к блоку:

стрелка слева это вход (это информация, данные, ресурсы которые преобразуются или расходуются функцией);

справа это выходы (это то что получается в результате выполнения функции);

сверху это управление (условие, при которых функция формирует правильный выход);

снизу это механизм (то, с помощью чего выполняется функция).

IDEFO-модель состоит из иерархии диаграмм, возникающих при декомпозиции функций. Каждый блок пронумерован, что определяет его место в иерархии. Диаграмма верхнего уровня состоит из единственного блока называемого контекстной диаграммой с номером А0 и детализируется в диаграммах последующего уровня блоками Al , А2, A3, . . . .

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

На ряду с диаграммами в состав IDEF0-модели входят текстовые объяснения и уточнения характеристик, потоков, соединений. Есть возможность создать глоссарий с определениями аббревиатур, ключевых слов и фраз, используемых в диаграммах[15].

Методология Unified Modeling Language (UML). Если сущность характеризуется не только разнообразными атрибутами, но и имет поведение, представляемое набором отдельных функций, то такую сущность называют классом, экземпляры класса называют объектами, функций называют методами класса. Такой подход включающий в себя анализ, проектирование и программирование называется объектно-ориентированный (ООП). Это так же называют и «объектно-ориентированное проектирование», и «объектно-ориентированный анализ»[10].

ER-моделирование является прототипом ООП, характеризующимся объектным подходом к анализу требований к программным продуктам.

В CASE-системах, которые реализуют такой подход, используют комплекс диаграмм, созданных с помощью унифицированного языка моделирования (Unified Modeling Language, UML).

Перечислим основные диаграммы UML шировок используемые для пироектирования (на самом деле диаграмм в UML больше):

- диаграммы прецедентов (Use-Case Diagram) описывает поведение аспекты систем, связывая акторов с прецедентами.

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

- диаграммы классов выделяют классы, их построение, ассоциации между классами;

- диаграммы объектов отображают комплекс объектов и взаимоотношения между ними в конкретный момент времени;

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

- диаграммы состояний отображают состояния системы с возможными переходами между состояниями, и описывают условия переходов;

- диаграммы развертывания представляют инфраструктуру в которой необходимо развернуть программную систему;

- диаграммы активности раскрывают алгоритмы, по которым совершаются процессы в системе[11].

Рассмотрим сравнительные характеристики инструментов проектирования бизнес-процессов. Все инструменты в таблице расположены в порядке увеличения функциональности и стоимости (Таблица 2).

Ramus Educational. Программа Ramus предназначе­на для описания бизнес-процессов организации на языке IDEF0 с системами классификации и кодирования. Разработчики рассматривают Ramus в качестве инструмента бизнес-анализирования для проеков по построению или реорганизации системы управ­ления предприятием.

Ramus использовует в проектах следующие классы:

реинжиниринг бизнес-процесса;

внедрение процессного управления;

построения системы управления качеством;

построения системы управления знаниями и др.

Ramus Educational имеет ориен­тацию на использование студентами вузов. Он не имеет ограничения по количеству, но ограничен по функционалу, например, доступена только локальная работа, атрибуты классификаторов ограничены.

Проект Open Ramus входит состав Ramus, который предоставляет базовые библиотеки Ramus (Ramus Core) на языке Java.

В Ramus Core входят следующие библиотеки:

для организации работ с данными;

для сохранения данных в файл;

для добавления стандартных типов данных;

для работы с СУБД.

Программное обеспечение Ramus создано на языке Java, поэтому считается кроссплатформенным.

В образовательной версии Ramus присутствуют функции:

- моделирования процессов по методологии IDEF0 и DFD;

-разработки систем классификации и кодирования организации отображающие внутренние связи и связи с моделью процессов;

- импорт/экспорт в формат IDL.

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

Данные хранятся в собственном формате частично совместимом с инструментом моделирования бизнес-процессов AllFusion Process Modeler, ранее называвшемся BPWin[16].

Visio обладает простой и доступной логикой моделирования процессов. Продукт отличается стандартными, привычными панелями управления в стиле MS Office и за счет интеграции с приложениями MS Office делает работы с ним легкой для неопытных пользователей. Но для оценки времени и стоимости требуется разработка отчетов, что довольно проблематично при использовании этого продукта. Для анализа бизнес-процесса типовых отчетов явно не хватает. Несмотря на этот недостаток Visio одно из популярных средств для описания бизнес-процессов. Visio поддерживает стандартные форматы IDEF и UML для описания бизнес-процессов, так же при необходимости возможна разработка собственных форматов.

BPWIN – обладает большими возможностями для анализа, не в ущерб простоте использования. Важной функцией BPWIN является проверка целостности и согласованности модели. Это позволяет обеспечить логическую четкость в определении и описании элементов диаграмм, а также позволяет проверить целостность связей между диаграммами. BPWIN корректирует часто встречающиеся ошибки моделирования. Так же инструмент позволяет описать индивидуальные свойства элемента диаграммы. Ограничения на данную систему накладывает стандарт IDEF являющийся основой системы, в стандарте существует жесткий свод правил при построении модели. Это затрудняет описание нестандартных объемных процессов, но значительно облегчает описание простых процедур. Попытка описать сложный процесс создает бесконечное число взаимосвязанных схем, на первый взгляд очень похожих, что делает понимание процесса практически не возможным.

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

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

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

Итак, ARIS рассматривает организацию с 4 разных ракурсов, отражающих разные взгляды на предприятие и имеющую разную глубину.

Для описания организации разработано 85 типов моделей (на практике используют не больше 6-7 типов моделей). ARIS Toolset достаточно сложна для освоения и моделирования организации, но в результате получается модель понятная даже неподготовленным пользователям и сотрудникам, это экономит и время и денежные средства на обучение и организацию сотрудников компании.

Rational Rose - CASE-средство автоматизируещее этапы анализа и проектирования, также генерирует коды на разных языках и выпускает проектную документацию. Rational Rose создан на основе принципов объектно-ориентированного анализа и проектирования. Основной вариант Rational Rose имеет возможность разработки проектной документации в виде комплекса диаграмм и спецификаций, и на основе этого комплекса генерирует код в C++. В Rational Rose содержит комплекс средств реинжиниринга программ, которые обеспечивают использование уже имеющихся программных компонент в новом проекте.

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

Таблица 2

Возможности/ Инструментальная среда

Ramus Educational

MS Visio XP

BPWin 4.0

ARIS Toolset 5.0

Rational Rose

Поддерживаемый стандарт

IDEF0, DFD

UML, IDEF0

IDEF0, 1DEF3, DFD

Большое количество нотаций -(частично - DFD, ERM, UML)

ОМТ, UML, нотация Буча

Система хранения данных модели

Модели хранятся в файлах

Модели хранятся в файлах

Модели хранятся в файлах

Объектная база данных

Модели хранятся в файлах

Ограничение на размер базы данных

Нет. Размер базы данных ограничивается вычислительными ресурсами

Нет. Размер базы данных ограничивается вычислительными ресурсами

Нет. Размер базы данных ограничивается вычислительными ресурсами

Нет. Размер базы данных ограничивается вычислительными ресурсами

Нет. Размер базы данных ограничивается вычислительными ресурсами

Возможность групповой работы

Есть в платной версии

Есть. Используется Model Mart.

Есть. Используется ARIS Server.

Есть. Rational Suite, Visual Source Save

Ограничение на количество объектов на диаграмме

Нет

В зависимости от используемого стандарта (есть в IDEF0)

От 2 до 8.

Нет.

Нет

Возможность декомпозиции

Неограниченная декомпозиция

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

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

Неограниченная декомпозиция. Возможна декомпозиция на различные типы моделей.

Неограниченная декомпозиция. Возможна декомпозиция на различные типы моделей.

Формат представления моделей

IDEF0

Не регламентируется

Стандартный бланк IDEF с возможностью его отключения

Не регламентируется

Не регламентируется

Удобство работы по созданию моделей

Простая панель управления

Простая панель управления, есть выравнивание объектов, есть undo.

Простая панель управления, нет выравнивания объектов, нет undo.

Сложная панель управления, есть выравнивание объектов, есть Undo.

Сложно. Есть однократное Undo. Есть выравнивание объектов.

UDP - свойства объектов, определяемые пользователем

Количество UDP не ограничено. Количество типов ограничено.

Количество UDP не ограничено. Количество типов ограничено.

Большое, но ограниченное количество свойств, количество типов ограничено.

Количество UDP не ограничено, количество типов ограничено

Возможность анализа стоимости процессов

Нет

Нет встроенных возможностей анализа

Упрощенный анализ стоимости по частоте использования в процессе. Возможность экспорта в Easy ABC.

Есть. Возможность использовать ARIS ABC.

Нет встроенных возможностей анализа.

Генерация отчетов

Есть в платной версии

Создание отчетов по UDP с помощью Visio Report

RPT Win, возможна визуальная настройка отчетов, включающая расчет по формулам с использованием UDP

Создание отчетов на основе стандартных и настраиваемых пользователем макросов Visual Basic.

Сложность разработки нестандартных отчетов

Сложно

Сложно

Просто

Сложно

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

Для проектирования процесса страхования ТС организации была выбрана методология IDEF0 как наиболее простая и понятная для широкого круга сотрудников организации и достаточно полно описывающая заданный бизнес процесс. Т.к. методология IDEF0 реализуется в большинстве рассмотренных продуктов, то будет логично выбрать самый простой и доступный продукт Ramus Educational.

1.3 Моделирование процесса учета договоров автострахования на текущий момент времени

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

Рисунок 2. Контекстная диаграмма «Страхование ТС организации»

Рисунок 3. Детализация контекстной диаграммы

На рисунке 3 представлена детализация бизнес-процесса Страхование ТС организации. При первоначальном поступлении ТС в организацию, либо при эксплуатации ТС проверяется срок истечения обязательного страхования ОСАГО, если срок истек либо подходит к концу договор страхования заключается \ продлевается заведующим автохозяйством и оплачивается бухгалтером. После того как обязательная страховка оформлена необходимо принять решение об дополнительной страховке КАСКО, для этого изучается информация о страховых случаях (данный процесс детализирован диаграммой А3). После принятия решения о страховании КАСКО заключается договор страхования и оплачивается бухгалтером (Рисунок 4).

Рисунок 4. Детализация диаграммы А3

Для изучения страховых случаев (Рисунок 4) заведующий автохозяйством и руководитель изучают стоимость ущерба при страховых случаях, какая часть ущерба было покрыто ОСАГО, стоимость страховки КАСКО покрывающего ущерб, составляют общий отчет для принятия дальнейшего решения.

ГЛАВА 2. ИЗМЕНЕНИЕ БИЗНЕС-ПРОЦЕССА

2.1 Предприятия по улучшения процесса страхования ТС организации

В улучшение бизнес-процессов входят методы и подходы, дающие руководителю компании возможность повышения эффективности ее работы. Цель улучшения бизнес-процессов сделать их более эффективными[18].

В организации периодически улучшающей свои бизнес-процессы:

  1. Руководитель и сотрудники изучают существующие бизнес-процессы. Эти процессы стараются представить в виде схем, используемых в принятых методах работы.
  2. Качественное выполнение бизнес-процессов можно оценить используя формальные показатели, которые оценивают качество базовых ресурсов и результатов и измеряют эффективность работы.
  3. Руководитель организации регулярно выделяет время и средства для совершенствования бизнес-процессов. Вложения могут быть направлены на улучшение отдельной операции, либо на работу организации в целом.
  4. Организация, не занимающаяся менеджментом бизнес-процессов, предпринимает шаги по улучшению от случая к случаю, без системного подхода, что приводит к наименьшему результату или не приводит к результату вообще. Улучшение бизнес-процессов — Инструмент улучшения бизнес-процесса используют в организации на любом уровне.

Приведем формальные методики и стандарты совершенствования бизнес-процессов (Таблица 3).

Формальные методики и стандарты совершенствования бизнес-процессов

Таблица 3

Название

Описание

Шесть сигм (Six Sigma)

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

Всеобщее управление качеством (Total Quality Management, TQM)

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

ISO 9000

Серия стандартов систем управления качеством (ISO). Эти стандарты не гарантируют качество конечного товара или услуги — скорее они удостоверяют тот факт, что компания использует сертифицированные бизнес-процессы. Стандарты ISO 9000 находятся в ведении структур, отвечающих за аккредитацию и сертификацию.

Реинжиниринг бизнес-процессов (BPR)

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

С чего начинается улучшение бизнес-процессов

Видов событий, которые запускают процесс совершенствования бизнес-процесса:

неэффективные действия;

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

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

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

Шесть этапов совершенствования бизнес-процессов

Качественный менеджмент бизнес-процессов подразумевает системный подход к совершенствованию бизнес-процессов.

Для совершенствования бизнес-процесса по страхованию ТС и учету договоров страхования организации применим шесть ступеней:

  1. Планирование
  2. Анализ
  3. Редизайн
  4. Привлечение ресурсов
  5. Внедрение
  6. Непрерывное совершенствование

Планирование улучшения бизнес-процессов

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

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

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

заведующему автохозяйством сложно отслеживать и анализировать информацию в связи с постоянным изменением или дополнением автохозяйства;

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

  1. Выбираем процесс, который планируем улучшить. После проведенного анализа видно, что процесс учета договоров страхования ТС нуждается в улучшении, это сократит количество штрафов и уменьшит недовольство сотрудников компании.
  2. Определяем масштаб, цел изменения. Целью изменения процесса является снижение количество штрафов и своевременное страхование ТС.
  3. Собираем команду. В команду по совершенствованию бизнес процесса будет входить руководитель организации, который будет контролировать внедрении нового бизнес-процесса на всех уровнях. Заведующий автохозяйством, который будет разрабатывать новый бизнес процесс совместно с разработчиком. И сам разработчик, т.е. автор дипломного проекта, который проводит анализ бизнес процесса и совершает действия направленные на автоматизацию заданных функций.
  4. Грамотно поставить задачу команде. Для постановки задачи были разработаны диаграммы бизнес-процесса «Как есть» и «Как должно быть» для детального анализа и выбора метода решения.

2.2 Модель бизнес-процесса «Как должно быть»

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

Рисунок 5. Контекстная диаграмма «Страхование ТС организации»

Контекстная диаграмма (Рисунок 5) не претерпела больших изменений по сравнению с диаграммой «Как есть», но на выходе мы видим, что после работы системы мы будем получать больше количества информации для руководителя, такой как отчет об оплате страховки, отчет об истекающих страховках, отчет о страховых случаях и покрытии страховкой.

Рисунок 6. Детализация контекстной диаграммы

После внедрения информационной системы вся информацию о страховках и страховых случаях можно будет легко получить из системы, это уменьшит время на анализ и принятие решения (Рисунок 6). На детализации видно, что вся информация содержится в отчетах от системы и детализация блока «Изучение случаев и предложений страховых компаний» не требуется.

ГЛАВА 3. РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ ВЕДЕНИЯ ДОГОВОРОВ АВТОСТРАХОВАНИЯ

3.1 Техническое задание на разработку ИС «Автострахование»

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

ИС позволяет учитывать договора автострахования и получать необходимые сведения договорах, страховых случаях и оплатах по ним. Упрощает анализ рентабельности страховки.

Наименование программного продукта: Информационная система «Автострахование»

Информационная система «Автострахование» позволяет автоматизировать такие события как:

Поступление ТС на баланс организации;

Заключение договоров ОСАГО и КАСКО с информацией по срокам и лицам, допущенным для управления;

Оплату страховки;

Учет страховых случаев с привязкой к договору;

Окончание срока страхования ТС;

Хранение данных о предложениях страховых компаний.

Основания для разработки:

Дальнейшее развитие организации не возможно без автоматизации процесса страхования ТС, т.к. количество ТС растет, вместе с тем растет и объем работы по страхованию[17].

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

ООО «ДоставимСами» обеспечена техническими средствами, такими как ПК, но не обеспечена программными средствами автоматизации.

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

Разделять пользователей руководителя, заведующего автохозяйством и бухгалтера;

Предоставлять пользователю возможность быстрого поиска по всем параметрам разработанной ИС связанным с конкретным объектом;

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

Назначение разработки:

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

Требования к программе.

Используемый язык программирования:

Встроенный язык программирования 1С на платформе 1С:Предприятие.

Определение требований к программе:

хранение, поиск и обработку информации о договорах страхования;

поддержку классификаций и тезаурусов, что обеспечит тематический поиск;

возможность выводить данные о условиях договора, стоимости, страховых случаях, лицах, допущенных до управления;

возможность фиксировать действие заключения договора страхования;

вывод результатов поиска на экран и на принтер;

Требования к надежности программы:

Защита от несанкционированного доступа;

Надежность хранения информации;

Контроль вводимой информации[20].

3.2 Характеристика платформы 1С:Предприятие

Прикладные решения в «1С: Предприятие» на уровне технологической платформы подчиняются правилам объектно-ориентированного программирования [2].

Платформа «1С: Предприятие» визуально описывает структуру данных, записывает программный код в тех узлах приложения к которым он относится, описывает запросы, интерфейсы, отчеты, отладку программного кода. В платформу входят следующие возможности:

возможности ролевых настроек прав;

возможность диагностики выполнения программного кода в приложении;

возможность сохранить архив с действиями пользователя;

возможность создать обновления;

возможность интеграции с другими приложениями;

возможность синхронизации данных с уже работающими приложениями;

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

При разработке программного продукта на «1С: Предприятии» можно воспользоваться следующими инструментами:

инструмент визуального описания структур данных;

инструмент написания программного кода;

инструмент визуального описания запросов;

инструмент визуального описания интерфейса;

инструмент описания отчетов;

инструмент отладки.

Платформа содержит развитую справочную систему, инструмент по созданию дистрибутивов, возможность удаленно обновить приложение, сравнить и объединить приложения, создать Web-приложение и приложение для КПК, а также содержит поддержку коллективной разработки, версионирования и пр.

«1С: Предприятие» как предметно-ориентированной среды разработки характеризуется особым отношением к подбору технологических возможностей, которые предоставляются разработчику. «1С: Предприятие» поддерживает подключение других (внешних) программных модулей. Но ориентируется на предоставление разработчику готовых технологий решения актуальных для задач автоматизации бизнеса. Разработчик прикладных решений задействует необходимые и современные технологии своевременно, максимально просто и без радикальных изменений в своем приложении[4].

С помощью «1С: Предприятие» можно автоматизировать любой технологический процесс, что делает его незаменимым в решении проблем автоматизации разных областей бизнеса.

Разумеется, у всех преимуществ предметно-ориентированной среды есть и обратная сторона. В отличие от универсальных средств, здесь имеются ограничения в выборе технологических решений и возможностях их «тонкой» настройки. Многие технологические решения определены в самой модели и не могут быть изменены разработчиком приложения. Например, в «1С:Предприятие» он не имеет прямого доступа к базе данных, ему нужно действовать теми средствами, которые использует модель «1С:Предприятие». В универсальных средствах можно все и можно произвольно выбирать любое сочетание технологических решений.

3.3 Реализация ИС «Автострахование»

При начале работы открывается главное окно (Рисунок 6), в котором происходит основная работа по учету договоров автострахования [1].

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

Рисунок 6. Главное рабочее окно

Следующим этапом работы будет заполнение справочников Транспортные средства и Физические лица, для их заполнения так же необходимо заполнить связанные с ними дочерние справочники: Должности, Марка ТС, Категория, Тип ТС. Справочник "Договора автострахования» заполняется автоматически на основе документа «Заключение договора».

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

Документ «Поступление ТС» отражает поступление транспорта на баланс организации (Рисунок 7).

Рисунок 7. Документ «Поступление ТС»

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

В документе присутствует контроль заполнения. Для варианта страхования ОСАГО заполнять доп. условия по страхованию не обязательно, как правило, они не влияют на стоимость страховки. При проведении этого документа автоматически создаются договора страхования в справочнике.

Рисунок 8. Документ «Заключение договора страхования»

После записи и проведения документа «Заключение договора страхования» на основании его вводится документ об оплате страховки «Оплата страховки» (Рисунок 9).

Рисунок 9. Документ «Оплата страховки»

Регистрация страховых случаев с их стоимостью так же совершаются созданием документа «Страховой случай» (Рисунок 10).

Рисунок 10. Документ «Страховой случай»

Чтобы списать транспортное средства с баланса организации вводят документ «Списание транспортного средства»(Рисунок 11).

Рисунок 11. Документ «Списание транспортного средства»

В результате ведения учета в данной системе мы можем получить следующие отчеты «ТС на балансе», «Рентабельность страховки», «Оплаты», «Истекающие договора» (Рисунок 12,13,14).

Рисунок 12. Отчет «ТС на балансе»

Отчет формируется в результате обработки данных о поступлении и списании ТС.

Рисунок 13. Отчет «Рентабельность страховки»

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

Рисунок 14. Отчет «Истекающие договора»

Отчет выводит данные о договорах с истекающим или уже истекшим сроком действия до определенной даты. Так же договора, которые истекают до начала следующего месяца подсвечиваются красным в главном окне.

Разработанная ИС отвечает всем заявленным требованиям и логике разработанного бизнес-процесса.

ЗАКЛЮЧЕНИЕ

При курсовом проектировании была проведена следующая работа:

Были выявлена предмет, объект, цель моделирования и сформулированы задачи исследования

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

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

Построена модель бизнес процесса страхования ТС на данный момент времени с помощью продукта Ramus Educational.

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

Построена модель бизнес-процесса после проведенных мероприятий и внедрения разработанной ИС.

Сформулированы требования к ИС

Разработана и внедрена ИС «Автострахование».

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

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

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

СПИСОК ЛИТЕРАТУРЫ

  1. Ажеронок В.А. Разработка управляемого интерфейса Ажеронок В.А., Островерх А. В., Радченко М. Г., Хрусталева Е. Ю. .– М.: Фирма 1С, 2010. – 723 с.
  2. Архитектура системы программ ««1С: Предприятия». – М.: Фирма «1С». – 2003. – 34с.
  3. Бартеньев О.В. 1С: Предприятие 8.0: опыты программирования. – М.: Диалог-МИФИ, 2005. – 464с.
  4. Габец А. П. 1С: Предприятие 8.1. Простые примеры разработки / А. П. Габец, Д. И. Гончаров. – М.: Фирма 1С, 2008. – 382 с.
  5. Гончаров Д. Сертифицированный курс. Введение в конфигурирование в системе «1C:Предприятие 8.1». Основные объекты. – М.: Фирма 1С, 2006.
  6. Громова О. Методическое пособие по конфигурированию. – М.: Объединение «Все для главбуха», 2001., – 95 с
  7. Колесов А. Интеллектуальные анализ данных и прогнозирование в «1С: Предприятии 8.0» // РС Magazin. – 2006. - №8.
  8. Колесов А. Полезные советы от разработчиков фирмы «1С» // РС Magazin. – 2006. - №6.
  9. Колесов А. Экономическая и аналитическая отчетность в «1С:Предприятии 8.0» // РС Magazin. – 2006. - №6.
  10. Маклаков С.В. BPWin и ERWin. CASE – средства разработки информационных систем. – М.: ДИАЛОГ – МИФИ, 1992.
  11. Митичкин С.А. Разработка в системе 1С Предприятие 8.0. 2006 г. 413 стр. с ил.
  12. Мюллер Р. Дж. «Базы данных и UML. Проектирование» - М: Изд. дом «ЛОРИ», 2002 – 420 с.
  13. Нуралиев C. Платформа «1С: Предприятие» как средство разработки бизнес-приложений // журнал «РС Magazine/RE», № 11, 2006.
  14. Радченко М. Г. «1С: Предприятие 8.1». Практическое пособие разработчика. – М.: Фирма 1С, 2007. – 512 с.
  15. Романова Ю.Д. Информатика и информационные технологии: Учеб. пособие— 3-е изд., доп. — М.: Эксмо, 2008. - 592 с.
  16. Семакин И.Г., Шестаков А.П. Основы алгоритмизации и программирования: Учебник для сред. проф. образования / И.Г. Семакин, А.П. Шестаков. - М.: Издательский центр "Академия", 2008. - 400 с.
  17. Сибилев В.Б. Проектирование баз данных: учебное пособие. – Томск:ТМЦДО, 2007
  18. Титоренко Г.А. Информационные технологии управления: Учеб. пособие для вузов — 2-е изд., доп. — М.: ЮНИТИ-ДАНА, 2003. - 439 с., с.34
  19. Тимофеев Г.С. Конфигурирование и администрирование 1С: Предприятия / Г.С. Тимофеев, Д.А. Шумейко. – Изд. 3-е. – Ростов н/Д: Феникс, 2005. – 319с.
  20. В.В. Трофимов Информационные системы и технологии в экономике и управлении / Под редакцией В.В. Трофимова. - М.: Юрайт, 2009. - 528 c.
  21. Хрусталева Е. Ю. Разработка сложных отчетов в «1С: Предприятие 8». Система компоновки данных. – М.: Фирма 1С, 2008. – 513 с.
  22. Свободная энциклопедия Википедия [Электронный ресурс]. Режим доступа − http://wikipedia.org/, свободный.
  23. «1С:Предприятие» 8 [Электронный ресурс]. – Режим доступа: http://v8.1с.ru/, свободный