Файл: Моделирование бизнес-процесса страхования гражданской ответственности..pdf

Процесс моделирования любой системы в IDEF0 начинается с определения контекста, т. е. самого абстрактного уровня описания всей системы. В контексте было включено определение предмета моделирования, целей и точек зрения на модель.^[30]

На диаграмме контекста A-0 показана система управления процессом, показанная на рисунке 9 а).

Рис.9 а) Контекстная диаграмма

Рис. 9 б) Диаграмма декомпозиции

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

Консультации. Входящая информация - это вопросы клиента, исходящая информация – это ответы консультанта. Это просто: сотрудник, консультант по использованию законодательных документов и внутренних инструкций, находит ответ на вопрос и сообщает об этом клиенту по телефону.

Рис. 19 в) процесс проведения консультаций

Процесс консультаций проходит в 2 этапа: поиск информации и ответное сообщение^[31]

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

Сотрудник получает запрос и находит ответ на него либо из аналогичных случаев, либо из законодательства, правил, инструкций и других источников (рис. 19 г).

Рис. 19 г) Процесс поиска информации

Если клиента удовлетворяет полученная информация, мы можем перейти к следующему процессу - заключению договоров (рис.19 д). Это также происходит в 2 этапа: предварительные интервью и фактическое заключение контракта. Входящая информация - это документы клиента и решение клиента. Решением клиента может быть отказ в страховании - исходящей информации. В случае положительного решения соглашение заключено. Исходящая информация - это страховой полис.^[32]

Рис. 19 д) Процесс заключения договоров

В случае страхового случая клиент получает страховые выплаты (Рис.19 e). Этот процесс происходит в 4 этапа:

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

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

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

- в случае положительного решения, кассир производит платежи клиенту. Исходящая информация – утверждённый акт осмотра.^[33]

Рис.19 е) Страховые выплаты

Прежде чем выплатить страховое возмещение, сотрудники центра рассмотрят документы клиента.^[34] Этот процесс происходит следующим образом (рис. 19 ж):

Рис. 19 ж) Рассмотрение документов

Клиент, когда наступает страховой случай, обращается к страховому центру.

Сотрудники центра изучают документы и принимают решение об осмотре транспортных средств или нет.^[35]

3.2.2. Построить диаграммы IDEF3

В отличие от IDEF0, который представляет собой смоделированную систему как набор действий, IDEF3 является методом моделирования действий как последовательности событий, а также участвует в объектах событий.^[36]

Построим схему IDEF3-процесса контракта (рис. 20 a):

Рис. 20 а) Заключение договора

Из рисунка 20 а) видно, что заключение контракта состоит из следующих последовательных процессов: осмотр транспортных средств, заполнение инспекционного свидетельства, вид страхования, получение платежа и выдача полиса. Клиент может выбрать следующие виды страхования: КАСКО Страхование автомобиля от угона и ущерба; ОСАГО - обязательное страхование гражданской ответственности владельцев транспортных средств; ДСАГО - ряд дополнительных программ: страхование водителя и пассажиров от аварии, эвакуация с места аварии, страхование только по риску угона. Клиент может выбрать только один вид страхования.^[37]

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

Рис. 20 б) Осмотр автотранспорта

3.2.3. Анализ цен

Анализ затрат - это соглашение об учетной записи, используемой для сбора затрат, связанных с работой, для определения общей стоимости процесса. Для этого вам нужно будет создать Центры затрат (Cost centers), которые могут быть интерпретированы как статьи расхода. При проведении анализа затрат в BPwin сначала устанавливаются единицы времени и денег, а затем описываются центры затрат и наконец, для каждой операции на диаграмме декомпозиции назначается продолжительность, частота выполнения этой работы в рамках общий процесс (частота) и сумма для каждого МВЗ, т. е. устанавливают стоимость каждой работы по каждой статье потребления. Этот очень упрощенный принцип расчета справедлив, если работа выполняется последовательно.^[38][39]

Возьмём диаграмму «Страховой платеж» и рассчитаем стоимость. Мы предполагаем, что вовлечены в этот процесс: Менеджер, который принимает решение; три инспектора, которые рассматривают документы и проводят проверку транспорта; один кассир, который дает деньги. Ежедневно получаем 40 заявок на страхование. Предположим, что зарплата инспектора - 300 р / сут. 500 р / сут, а кассир - 200 р / сут. Аналогичным образом распределяем диаграммы затрат «Консультации» и «Заключение договора». Создадим следующие центры затрат:

зарплата;

оборудование;

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

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

Результаты анализа затрат приведены в таблице 4:

Стоимостной анализ процесса страхования Таблица 4

Как видим, на процесс страховых выплат уходит 5300руб. день.

3.2.4. Построение DFD-диаграмм

Для документирования механизмов передачи и обработки информации в системе используются диаграммы потоков данных (Data Flow Diagrams). Диаграмма DFD обычно построена для визуализации текущей активности системы документооборота в вашей организации. Часто диаграммы DFD используются в качестве дополнительной модели бизнес-процессов, запущенных в IDEF0.^[40]

Диаграмма DFD показана на рисунке 21:

Рис.21. DFD-диаграмма «Беседа с клиентом»

На диаграмме показан процесс разговора с клиентом, в котором он принимает решение о заключении договора или нет.^[41]

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

3.2.5. Построение диаграммы дерева узлов и диаграмм FEO

Дерево узлов - представление отношений между родительскими и дочерними узлами модели IDEF0 в виде древовидного графика. Узлы диаграмм используют традиционное дерево иерархии, в котором верхний узел (блок) соответствует контекстной диаграмме и декомпозиции нижнего уровня потомства.^[42]

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

Рис. 22 Диаграмма дерева узлов

FEO-диаграмма - диаграмма-иллюстрация отдельных фрагментов модели и иллюстрирует альтернативные точки зрения или для специальных целей, которые явно не поддерживаются синтаксисом IDEFO. FEO-диаграмма позволяет проиллюстрировать различные сценарии, чтобы показать разные точки зрения, чтобы показать отдельные части, которые явно не поддерживаются синтаксисом IDEF0.^[43] FEO-диаграмма, показанная на рисунке 23.

Рис. 23. FEO-диаграмма

3.3. Описание модели TO-BE

Таким образом, в нашей модели рассматриваются все ключевые процессы функционирования системы. Однако есть недостатки, в частности в процессе консультаций. Поиск правильной информации для клиента у сотрудника тратится время, может потребоваться повторная обработка. Это не всегда может удовлетворить клиента. Поэтому целесообразно ввести процесс онлайн-консультаций, который ускорит процесс (рис. 24).

Рис. 24. Модель TO BE

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

ГЛАВА 4. Построение модели данных в Erwin

ERwin - средство разработки структуры базы данных (БД). ERwin сочетает в себе графический интерфейс Windows, инструменты для рисования редакторов ER-диаграмм для создания логической и физической модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных.^[45]

4.1. Проектирование логической и физической модели данных

В Erwin есть два уровня моделирования: логический и физический.

На логическом уровне не рассматривается использование конкретной СУБД, которая не определяет типы данных (например, целое или действительное число) и не определяет индексы для таблиц. Логическая модель данных процесса страхования ответственности перед третьими лицами изображена на рис. 25.

Рис. 25. Логическая модель данных

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

Таблица 5

Для каждого объекта мы определяем набор атрибутов.

Сущность «Клиент» содержит следующие атрибуты: «Идентификатор клиента» - первичный ключ; «номер автомобиля», «номер сотрудника» - внешние ключи и атрибуты «имя», «дата рождения», «адрес» и «паспорт», описывающие личные данные клиента.