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

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

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

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

IDEF0 является частью семейства языков моделирования IDEF в области разработки программного обеспечения и построен на языке функционального моделирования StructuredAnalysisandDesignTechnique (SADT).

Метод функционального моделирования IDEF0 предназначен для моделирования решений, действий и действий организации или системы. Он был получен из установленного языка графического моделирования StructuredAnalysisandDesignTechnique (SADT), разработанного Дугласом Т. Росс и SofTech, Inc. В своей первоначальной форме IDEF0 включает в себя определение языка графического моделирования (синтаксис и семантика) и описание комплексной методологии разработки моделей.

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

Для дополнения IDEF0 для систем с интенсивным использованием данных используется связанный с ним метод определения интеграции для информационного моделирования (IDEF1x). Стандарт IDEF0, публикация 183 федеральных стандартов обработки информации (FIPS 183) и стандарт IDEF1x (FIPS 184) поддерживаются Национальным институтом стандартов и технологий (NIST).

2.3.2. IDEF3

IDEF3 или интегрированное определение для метода описания процесса — это метод моделирования бизнес-процессов, дополняющий метод IDEF0. Метод IDEF3 — это метод описания потока процесса, предназначенный для понимания как работает определенная система.

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

Различие между описаниями и моделями, хотя и тонкое, является важным в IDEF3, и оба имеют точное техническое значение.

Термин "описание" используется в качестве зарезервированного технического термина для обозначения записей эмпирических наблюдений; то есть описания записывают знания, которые берут начало в наблюдениях или опыте или основаны на них.

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

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

Данный метод является частью семейства языков моделирования IDEF в области системной и программной инженерии.

2.3.3. DFD

Диаграмма потока данных (DFD) — это способ представления потока данных процесса или системы (обычно информационной системы). DFD также предоставляет информацию о выходах и входах каждого объекта и самого процесса. Схема потока данных не имеет никакого потока управления, нет никаких правил принятия решений и никаких циклов. Конкретные операции, основанные на данных, могут быть представлены в виде блок-схемы.

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

Диаграмма потока данных является частью инструментов моделирования структурного анализа. При использовании языка UML диаграмма активности обычно берет на себя роль диаграммы потока данных.

2.4. Выбор средства проектирования и нотации

В качестве нотации проектирования бизнес-процесса выбрана IDEF0, как наиболее полно показывающая работу процессов.

В качестве средства проектирования выбрано BPwin, потому что данная программа обладает следующими преимуществами:

• Простой пользовательский интерфейс, что упрощает процесс моделирования.
• Для каждого процесса можно указать дополнительные свойства и сохранять их в моделях и включать в отчеты.
• Контроль корректности моделей. За счет встроенных средств BPwin осуществляет контроль некорректных связей и представления элементов моделей. Это повышает качество моделей и улучшает возможности интеграции с другими средствами моделирования.

3 ПРОЕКТИРОВАНИЕ ПРОЦЕССА

3.1 Моделирование процесса «как есть»

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

Определим параметры бизнес-процесса страхования автотранспорта:

• Владелец процесса – страховая компания;
• Вход процесса – документы для оформления страхования;
• Выход процесса – документы о страховании.

Нотация IDEF0 показывает процесс в целом и разбивает его на подпроцессы. Диаграмма первого уровня представлена на рисунке 1.

Рисунок – диаграмма А-0

На вход подаются документы, необходимые для заключения страхового договора: паспорт, диагностическая карта автомобиля, водительское удостоверение, ПТС.

Механизмом процесса является менеджер страховой компании.

Управление осуществляется с помощью законодательства.

Выходной информацией является договор страхования и страховой полис.

Чтобы понять, как происходят бизнес-процессы, необходимо провести декомпозицию (Рисунок 2).

Рисунок – диаграмма А0

Процесс можно декомпозировать на следующие подпроцессы:

• Подача документов;
• Проверка документов;
• Расчет страховой суммы;
• Заключение договора.

Механизмом всех процессов является менеджер. Управление осуществляется законодательством.

Входные данные для подачи документов:

• Заявление на заключение договора и выдачу страхового полиса;
• Паспорт;
• ПТС;
• Диагностическая карта транспорта;
• Водительские права.

Выходные данные:

• Документы клиента.

Входные данные для процесса проверка документов:

• Документы клиента.

Выходные данные:

• Возврат документов (в случае если в них есть ошибки);
• Успешная проверка документов.

Входные данные для расчета страховой суммы:

• Успешная проверка документов;

Выходные данные:

• Страховая сумма.

Входные данные для заключения договора:

• Проверенные документы;
• Страховая сумма.

Выходные данные:

• Договор;
• Страховой полис.

Рассмотрим подробнее процесс проверки документов (Рисунок 3).

Рисунок – декомпозиция блока А2

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

Также проведем декомпозицию процесса заключение договора (Рисунок 4).

Рисунок – декомпозиция блока А4

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

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

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

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

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

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

Чтобы снять нагрузку с работников предлагается автоматизировать следующие процессы:

• Подача документов;
• Проверка документов;
• Расчет сумм страхования.

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

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

Этим перечнем статистические и аналитические функции не ограничиваются и могут расширятся по мере необходимости.

3.3. Моделирование процесса «как будет»

Моделирование процесса «как будет» предполагает создание модели с учетом улучшений. Рассмотрим бизнес-процесс оформления страхования с учетом мероприятий, приведенных в параграфе 3.2.

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