Пример 1. Модель страхования автогражданской ответственности

Задача:

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

Построение модели:

На контекстной диаграмме А-0 отразим основные входные потоки, выходные данные, ресурсы и управление. Управляющими воздействиями здесь будут Законодательство и Инструкции. Ресурсами являются сотрудники центра и материальные ресурсы.

Рис.1

Далее, определим основные процессы страхования. Это будут:

консультации;

заключение договора;

страховые выплаты.

Отразим эти блоки на диаграмме первого уровня А0 (рис.2). Входными данными модели будут:

вопросы клиентов;

документы клиентов;

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

Кроме этого, страховщик обязан регулярно вносить обусловленную договором страхования плату (страховую премию).

Рис.2

Выходными данными модели будут:

отказ в страховании;

страховой полис и договор;

страховое возмещение.

Теперь создадим диаграмму «Консультации» (рис.3).

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

Рис.3

«Заключение договора» (рис.4) состоит из двух частей: Предварительная беседа и Оформление договора.

Рис.4

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

Рис.5

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

Рис.6

Для расчета стоимости и продолжительности работ потребуется создать Центры затрат (Cost centers), которые можно трактовать как статьи расхода. При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег, затем описываются центры затрат и, наконец для каждой работы на диаграмме декомпозиции назначаются продолжительность (duration), частота проведения данной работы в рамках общего процесса (frequency) и суммы по каждому центру затрат, то есть задается стоимость каждой работы по каждой статье расхода. Этот очень упрощенный принцип подсчета справедлив, если работы выполняются последовательно.

Возьмем, например, диаграмму А22: «Оформление договора» и проведем расчет стоимости. Будем считать, что в этом процессе участвуют: руководитель, который утверждает документы; четыре инспектора, которые заключают договоры страхования; один кассир, который принимает деньги. Ежедневно поступает 40 заявлений на страхование. Будем считать, что зарплата инспектора – 300 р/день, руководителя 500 р/день, а кассира – 200 р/день. Создадим следующие центры затрат:

зарплата;

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

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

В блок «Проверка транспорта» запишем всю дневную зарплату инспекторов (чтобы не делить ее на несколько частей) – 300рх4=1200р. Продолжительность проверки примем равной 0,2 час.

В блоке «Заполнение страхового полиса» определим, что на все полисы в день потребуется: 200р на расходные материалы и 50р на амортизацию оборудования. Продолжительность операции примем равной 0,3 час.

В блоке «Прием оплаты» запишем всю дневную зарплату кассира – 200р. Продолжительность операции примем равной 0,1 час. Затраты на расходные материалы – 50р, на оборудование – 50р.

В блоке «Подпись и выдача страхового полиса» запишем всю дневную зарплату руководителя – 500р, на расходные материалы – 50р, на оборудование – 0р. Продолжительность примем равной 0,1 час.

В блоке «Помещение копии страхового полиса в архив» запишем на расходные материалы – 30р, на оборудование – 20р. Продолжительность примем равной 0,1 час.

В результате на диаграмме будут отражены результаты расчета стоимости. А на диаграмме верхнего уровня будет выведена стоимость 2350р.

Если в свойствах модели мы укажем «отображать продолжительность» процессов, то получим, что общая продолжительность оформления договора составит 0,8 часа.

Имеется возможность создавать также Определенные Пользователем Свойства (User Defined Property, UDP). Каждой работе можно поставить в соответствие набор UDP и проанализировать результат в специальном отчете Diagram Object Report. Через UDP могут быть запущены другие документы и приложения.

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

Стрелки можно объединять и создавать иерархию данных. Например: город, дом, улица, - объединить в Адрес. Тогда, на верхний уровень будет выходить только адрес. Для этого надо сделать ответвление со стрелки и назвать его по-другому. Большим преимуществом BPWin по сравнению с другими изобразительными средствами является то, что при построении иерархических диаграмм потоки родительской диаграммы, входящие в дочернюю, автоматически переносятся туда. И, наоборот, выходящие из дочерней, сразу отображаются в родительской. Если в родительской диаграмме мы удаляем стрелку, то в дочерней ее вход заключается в скобки. Это очень удобно, так как позволяет отслеживать потоки между уровнями.

Рис.7

С помощью BPWin мы можем изобразить дерево функций (рис 8).

Рис.8

Дополнительно можно построить диаграммы потоков данных (DFD-диаграммы). Они отображены ниже. Их очень удобно демонстрировать руководству. В теории утверждается, что основой являются IDEF0-диаграммы, поскольку они отражают еще управление и ресурсы. Но вот этого, как раз, на верхнем уровне понимания и не требуется.

Рис.9

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

Рис.10

Посмотрим, какие функции будет выполнять страхователь. Для этого обратимся к модели IDEF0. Он будет:

задавать вопросы;

подавать документы;

подавать заявление о выплате страхового возмещения.

В качестве выходных представлений он может получить:

ответ на вопрос;

страховой полис;

страховое возмещение;

отказ в страховании;

отказ в выплате страхового возмещения.

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

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