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

Иногда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую “деталь” на входе в функциональный блок “Обработать на токарном станке” не имеет смысла отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных “концептуальных” интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте 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. Диаграмма этапа закрытия договора

страхования

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

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

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

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

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

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