Содержание:

Введение

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

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

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

Рассматриваемый процесс – ведение договора по страхованию автотранспортных средств.

В курсовой работе рассматриваются задачи:

- характеристика предметной области;

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

- построение модели «как есть» и модели декомпозиции процесса по методологии SADT (в стандарте IDEF0);

- выбор мероприятий совершенствования исследуемого процесса.

- построение модели процесса «как должно быть»;

Инструментом моделирования исследуемого процесса является программа BPWin, которая позволяет моделировать процессы в стандартах IDEF0, IDEF3, DFD.

Глава 1. Разработка моделей процесса «как есть»

1.1.   Описание предметной области. Постановка задачи

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

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

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

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

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

- заявление на страхование автотранспортного средства;

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

- финансы для уплаты страховых взносов при заключении страхового договора,

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

Исходная информация процесса поступает от клиентов компании.

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

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

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

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

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

Обоснование выбранной нотации. Для моделирования бизнес-процессов в курсовой работе выбрана известная методология SADT (Structured Analysis and Design Technique) (Технология структурного анализа и проектирования), которая широко применяется для проектирования процессов.

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

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

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

Графический язык IDEF0 прост и гармоничен. В основе методологии лежат четыре основных понятия.

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока может быть сформулировано как глагольном наклонении, так и отглаголенным существительным. Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

 Верхняя сторона имеет значение “Управление” (Control);

 Левая сторона имеет значение “Вход” (Input);

 Правая сторона имеет значение “Выход” (Output);

 Нижняя сторона имеет значение “Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.

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

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

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

Иногда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую “деталь” на входе в функциональный блок “Обработать на токарном станке” не имеет смысла отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных “концептуальных” интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение “туннеля” (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из “туннеля”) только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока – приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии – в таком случае, они сначала “погружаются в туннель”, а затем, при необходимости “возвращаются из туннеля”.

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги “распоряжение об оплате” глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

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

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

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

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

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

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

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

Широко применяемыми из специализированных программ для моделирования процессов с использованием стандарта IDEF0 являются программы Ramus и СА ERwin Process Modeler (ранее BPwin, затем AllFusion Process Modeler).

В курсовой работе для моделирования процессов использовалась специализированная программа - AllFusion Process Modeler.

Обзор CASE-средства AllFusion Process Modeler 7. AllFusion Process Modeler 7 (ранее BPwin)  - инструмент для моделирования, анализа, документирования и оптимизации бизнес-процессов. AllFusion Process Modeler 7 применяется для графического представления бизнес-процессов.

Основные возможности системы: поддержка различных технологий моделирования, анализ показателей затрат и производительности, интеграция процессов/данных.

Функциональные возможности AllFusion Process Modeler 7 (BPwin):

• Поддержка нескольких нотаций. AllFusion Process Modeler 7 (BPwin)  обеспечивает комплексное использование и автоматическое согласование самых популярных нотаций моделирования бизнес-процессов IDEF0 (рекомендации Госстандарта РФ, федеральный стандарт США), потоков работ IDEF3 (федеральный стандарт США) и потоков данных (DFD).
• Интуитивно-понятный графический интерфейс дает возможность выполнить анализ самой предметной области, интерактивная подсказка помогает ускорить процесс освоения продукта.
• Анализ показателей затрат и производительности. AllFusion Process Modeler 7 (BPwin) полностью поддерживает методы расчета себестоимости по объему хозяйственной деятельности (функционально-стоимостной анализ, ABC), который позволяет оценить стоимостные и временные характеристики бизнес-процессов.
• Свойства, определяемые пользователем (UDP). AllFusion Process Modeler 7 (BPwin) позволяет настроить сбор дополнительной существенной информации, введенная информация может быть отображена в отчетах, сгенерированных с помощью генератора отчетов .

Организационные графики. Организационная структура влияет на то, как описываются и выполняются бизнес-процессы. AllFusion Process Modeler 7 (BPwin) поддерживает точное описание ролей, которые определяют и распределяют по категориям задачи или работы внутри бизнес-процессов.

• Методы контроля корректности модели. Наличие контекстно-зависимой панели инструментов, невозможность создания в модели некорректных связей, автоматическая миграция граничных стрелок, возможность автоматического отслеживание дисбаланса граничных стрелок на дочерней и родительской диаграммах (туннели), возможность автоматической проверки наличия имен стрелок и имен функциональных блоков, наличия выходов и управлений; а также дополнительные диаграммы и всевозможные отчеты по содержимому модели - все это помогает автоматизировать процесс построения корректных моделей бизнес-процессов.

Интерфейс к средствам имитационного моделирования. Имитационное моделирование позволяет исследовать результаты изменений в динамике. Различные сценарии могут быть испытаны перед их исполнением, помогая найти оптимальное решение бизнес-задач. AllFusion Process Modeler 7 (BPwin) экспортирует модели потоков работ в надежную среду имитационного моделирования Arena для их анализа в режиме реального времени.

1.3 Моделирование бизнес-процесса «как есть»

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

Входами в процесс «Ведение договора по страхованию автотранспортных средств» являются: заявление на страхование от клиента; документы, необходимые для страхования автотранспортного средства; финансы, для уплаты страховых взносов; заявление о страховом случае, если он наступит.

Выходы рассматриваемого процесса: выплаты по страховому случаю, если он наступит; документы о закрытии договора (либо в случае окончания срока договора, либо по другим причинам).

Механизмом реализации исследуемого процесса являются сотрудники страховой компании (страховые агенты, страховые специалисты, руководитель компании и другие) и клиент.

Управляющие документы процесса: Законодательство РФ и Правила страхования транспортных средств (ТС).

По правилам методологии SADT и стандарта функционального моделирования IDEF0, основанного на этой методологии, разработана контекстная модель исследуемого процесса. Контекстная модель включает основной функциональный блок «Ведение договора по страхованию автотранспортных средств», а также входы, выходы, механизмы реализации (ресурсы) и управляющие документы процесса. Контекстная модель представлена на рисунке 1.

Рисунок 1. Контекстная модель процесса ведения договора по страхованию автотранспортных средств «как есть»

Затем разработана диаграмма декомпозиции основного процесса, который включает четыре этапа:

- заключение договора страхования автотранспортного средства,

- сопровождение договора страхования,

- урегулирование страхового случая, закрытие договора страхования.

Диаграмма декомпозиции процесса представлена на рисунке 2.

Рисунок 2. Диаграмма декомпозиции процесса ведения договора по страхованию автотранспортных средств «как есть»

Для большей детализации процесса и в соответствии с принципом декомпозиции разработаны диаграммы всех этапов-блоков процесса. Диаграмма 1-го этапа процесса «Заключение договора страхования автотранспортного средства» приведена на рисунке 3.

Этап реализуется за пять шагов:

- прием документов на страхование;

- согласование условий договора;

- оформление договора страхования;

- расчет страхового взноса;

- получение страхового взноса.

Этап выполняют сотрудник страховой компании и клиент, страхующий автотранспортное средство. Вход в процесс: заявление на страхование, документы для страхования (паспорт клиента, паспорт автотранспортного средства). Выходом процесса является подписанный договор страхования.

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

Рисунок 3. Диаграмма этапа заключения договора страхования,

«как есть»

Следующим этапом рассматриваемого процесса является сопровождение договора страхования. Его диаграмма показана на рисунке 4.

Этап сопровождения договора стоит из таких работ, которые выполняются на всем протяжении действия договора:

- контроль за поступлением страховых взносов,

- контроль за состоянием автотранспортного средства,

- формирование отчетов о ведении договора страхования.

Рисунок 4. Диаграмма этапа сопровождения договора

страхования, «как есть»

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

Затем разработана диаграмма этапа процесса – урегулирование страхового случая. Его диаграмма дана на рисунке 5.

Этап включает следующие шаги его реализации:

- проверка заявления о страховом случае,

- оценка убытков по страховому случаю (если оно реально произошло),

- принятие решения о выплате страховой премии,

- составление страхового акта,

- страховая выплата клиенту.

Рисунок 5. Диаграмма этапа урегулирования

страхового случая, «как есть»

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

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

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

Рисунок 6. Диаграмма этапа закрытия договора

страхования

Этап включает три шага:

- отслеживание сроков окончания договора страхования автотранспортного средства,

- проверка уплаты страховых взносов за период страхования,

- оформление документов о закрытии договора.

Вход в этап: страховой акт, договор страхования, выход – документы о закрытии договора. Реализуют этап сотрудники страховой компании.

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

Глава 2. Разработка моделей процесса «как должно быть»

2.1 Предлагаемые мероприятия по совершенствованию исследуемого бизнес-процесса

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

На базе анализа моделей рассматриваемого процесса варианта «как есть» было принято решение о внедрении ИС, что означает совершенствование процесса.

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

Выделяют основные виды страховой деятельности, подлежащие автоматизации:

Автоматизация страховой деятельности:

• автоматизация фронт-офиса и бэк-офиса,
• управление договорами прямого страхования,
• управление договорами перестрахования,
• ведение клиентских данных,
• урегулирование убытков и выплаты.

Автоматизация управления взаимоотношениями с клиентами:

• взаимодействие с клиентами,
• поддержка процесса продаж,
• работа call-центра,
• анализ клиентских данных,
• управление маркетинговыми данными.

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

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

Автоматизация управленческого учета:

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

На текущий момент часто используются дополнительные методы автоматизации деятельности страховых компаний:

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

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

На рынке программных продуктов представлено большое количество информационных систем: «Ортикон: ОСАГО», «1С: ОСАГО», «АДС: Управление центром страхования 8», «ПолисОфис: ОСАГО», «Ринти: ОСАГО 2.0», «1С: Управление страховой компанией», «Парус-Страхование», «Континент: Страхование», «1С: Страховая бухгалтерия». Любой их этих продуктов может быть применен для автоматизации рассматриваемого процесса.

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

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

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

Рисунок 7. Контекстная модель процесса,

«как должно быть»

На рисунке 8 показана диаграмма декомпозиции усовершенствованного процесса, из которой видно, что ИС в новой версии процесса применятся на всех шагах процесса.

Рисунок 8. Диаграмма декомпозиции процесса,

«как должно быть»

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

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

Рисунок 8. Диаграмма декомпозиции этапа заключения

договора страхования, «как должно быть»

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

Для успешной реализации этапа в ИС должны быть разработаны базы данных (БД) – БД взносов, БД состояния застрахованных автотранспортных средств, БД отчетов о ведении договоров. Кроме того, в процессе должны участвовать БД клиентов, БД автотранспортных средств и БД договоров о страховании.

Диаграмма модели этапа сопровождения договора страхования с применением информационной системы показана на рисунке 9.

Рисунок 9. Диаграмма декомпозиции этапа сопровождения

договора страхования, «как должно быть»

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

Диаграмма этапа в версии «как должно быть» показана на рисунке 10.

Рисунок 10. Диаграмма этапа урегулирования страхового случая,

«как должно быть»

Последний этап рассматриваемого процесса – закрытие договора страхования также может быть полностью реализован в информационной среде с использованием системы и сайта компании. Для его реализации должны быть разработаны БД документов и закрытых договоров. Кроме того применяются уже разработанные БД для данного процесса.

Диаграмма модели этапа закрытия договора страхования «как должно быть» показана на рисунке 11.

Рисунок 11. Диаграмма этапа закрытия договора страхования,

«как должно быть»

Заключение

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

На первом этапе исследования построены модели рассматриваемого процесса в версии «как есть». Модели построены в соответствии с одной из известных методологий моделирования процессов SADT и основанного на ней стандарта IDEF0. Построены контекстная модель процесса и выполнена его декомпозиция в двух уровнях. Для моделирования был проведен обзор программных средств, на основании которого выбрана прикладная программа BPWin.

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

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

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

В работе приведен обзор информационных систем страховых компаний.

Список использованной литературы

1. Веселова О. С. Внедрение централизованных информационных систем как способ реинжиниринга бизнес-процессов. – М.: Университет, 2016. – 459 c.
2. Елиферов В. Г. Бизнес-процессы. Регламентация и управление. – М.: ИНФРА. – М, 2017. - 320 c.
3. Ильин В.В Моделирование бизнес-процессов. Практический опыт разработчика Серия: Практика реального бизнеса. 2006 г. – 434 с.
4. Калянов Г. Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. – Финансы и статистика. 2006 г. – 241 с.
5. Маклаков С. В. Моделирование бизнес-процессов с Bpwin 4.0. – М.: Диалог-МИФИ, 2002. – 224 с.
6. Рыбаков, Михаил Юрьевич Бизнес-процессы: как их описать, отладить и внедрить. Практикум. – М.: Михаил Рыбаков, 2016. – 788 c.
7. Черемных С., Семенов И. Моделирование и анализ систем. IDEF-технологии: практикум. – М. Изд-во: Финансы и статистика, 2006 – 192 с.