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

Введение

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

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

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

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

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

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

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

- построение модели «как есть» и модели декомпозиции процесса по методологии 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 – модели. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.