Разработка личного кабинета страхования грузов для клиентов и сотрудников страховой компании средствами BPM-Платформы Pega

Чабанова Е.С.

Разработка личного кабинета страхования грузов для клиентов и сотрудников страховой компании средствами BPM-Платформы Pega

01.03.02 Прикладная математика и информатика

Математика

Дипломы

Вуз: Белгородский государственный университет - национальный исследовательский университет (НИУ «БелГУ»)

ID: 5c1a53237966e104f6f85294

UUID: d6d6bdf0-e5c6-0136-fcdc-525400005860

Язык: Русский

Опубликовано: около 6 лет назад

Просмотры: 51

Чабанова Е.С.

Источник: Федеральное государственное автономное образовательное учреждение высшего образования «Белгородский государственный национальный исследовательский университет»

Комментировать 0

Рецензировать 0

Скачать - 948,4 КБ

Поделиться работой

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «БЕЛГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ» ( Н И У « Б е л Г У » ) ИНСТИТУТ ИНЖЕНЕРНЫХ ТЕХНОЛОГИЙ И ЕСТЕСТВЕННЫХ НАУК КАФЕДРА ОБЩЕЙ МАТЕМАТИКИ РАЗРАБОТКА ЛИЧНОГО КАБИНЕТА СТРАХОВАНИЯ ГРУЗОВ ДЛЯ КЛИЕНТОВ И СОТРУДНИКОВ СТРАХОВОЙ КОМПАНИИ СРЕДСТВАМИ BPM-ПЛАТФОРМЫ PEGA Выпускная квалификационная работа обучающейся по направлению подготовки 01.03.02 Прикладная математика и информатика очной формы обучения, группы 07001406 Чабановой Елизаветы Сергеевны Научный руководитель д.т.н., профессор Аверин Г.В. БЕЛГОРОД 2018

ОГЛАВЛЕНИЕ ВВЕДЕНИЕ........................................................................................................ 4 ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И ПОСТАНОВКА ЗАДАЧИ................................................................................................... 7 1.1 Обзор предметной области страхования грузоперевозок ............ 7 1.2 Исследование проблем в оптимизации разработки программного обеспечения ................................................................................. 11 1.3 Выводы............................................................................................. 14 ГЛАВА 2. ВЫБОР ПРОГРАММНЫХ СРЕДСТВ ДЛЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ................................................. 15 2.1 Сравнение современных походов разработки программных продуктов ..................................................................................... 15 2.2 Преимущества использования BPM-систем в разработке корпоративного программного обеспечения ........................... 20 2.3 Обзор и сравнение с аналогами платформы разработки Pega BPM 7.3 ........................................................................................ 23 2.4. Выводы............................................................................................ 29 ГЛАВА 3. ПРОЕКТИРОВАНИЕ И ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ЛИЧНОГО КАБИНЕТА СТРАХОВОЙ КОМПАНИИ ..................... 30 3.1 Требования к программному продукту ........................................ 30 3.2 Требования к аппаратной части .................................................... 30 3.3 Архитектура процессов по страхованию грузов ......................... 32 3.3.1 Описание бизнес-логики личного кабинета страховой компании ........................................................................... 32 3.3.2 Кейс генерального договора ............................................. 38 3.3.3 Кейс регистрации заявки на Декларацию ....................... 39 3.3.4 Кейс формирования и оплаты Бордеро ........................... 40 3.3.5 Кейс регистрации наступления страхового события ..... 42 3.4. Описание интерфейса пользователя ........................................... 43 2

3.5 Тестирование разработанного функционала ............................... 47 ЗАКЛЮЧЕНИЕ ............................................................................................... 49 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ..................................... 51 ПРИЛОЖЕНИЕ А ........................................................................................... 53 3

ВВЕДЕНИЕ Концепция современных методик разработки программного обеспечения, далее ПО, подразумевает высокие темпы и качество реализации бизнеспроцессов для удовлетворения требований заказчиков. В свете такого рода обстоятельств со стороны компаний, предоставляющих услуги по разработке ПО, появляется необходимость в соответствии текущим требованиям, что является причиной и веским основанием для появления таких парадигм разработки программных продуктов, как BPM (Business Process Management). Данная концепция являет собой подход, реализующий все современные характеристики процесса разработки и программных продуктов в целом, такие как: гибкость, скорость, надежность, а также удобство взаимодействия с бизнесаналитиками и другими участниками разработки цифровых систем. Business Process Management – в контексте программирования является концепцией, рассматривающей предприятия, непрерывно бизнес-процессы адаптируемые как особые к постоянным ресурсы изменениям и полагающиеся на такие принципы, как понятность и их видимость в организации за счет моделирования с использованием формальных нотаций, использования программного обеспечения моделирования, симуляции, мониторинга и анализа бизнес-процессов, возможность гибкой и динамической переработки моделей бизнес-процессов силами и средствами участников процесса разработки ПО. BMP отвечает на вопросы, какая работа, на каких этапах и с какой целью выполняется. Так, применяя на деле эту парадигму компания-разработчик в сравнительно короткие сроки предоставляет заказчику качественный и гибкоредактируемый продукт, имеющий возможность достаточно быстро быть выведенным в работу и итеративно дорабатываться уже на этапе коммерческого использования. Это решает основную задачу компаний-представителей 4

коммерческого сектора – привлечение финансов и, соответственно, увеличение оборота внутренних денежных средств. В качестве системы разработки ПО, поддерживающей концепцию BPM, в данной работе будет использована платформа разработки Pega BPM, которая является лидирующей на рынке Business Process Management систем. Данная система на сегодняшний день применяется в реализации программных продуктов для многих сфер социальной деятельности, таких как медицина, банковский сектор, производство и высокие технологии, правительственный сектор, а также страховое дело. В области последнего, в данной работе будет описываться процесс автоматизации деятельности отдела страхования грузоперевозок для юридических лиц. На сегодняшний день в силу ужесточения правовых норм взаимодействия представителей бизнес-сектора значительно увеличилось количество необходимых для страхования объектов и процессов, что в свою очередь определило потребность в высоком темпе и объеме страхования. Для обеспечения данных требований компаниям-страховщикам необходимы строго налаженные процесс и инфраструктура занимающихся соответствующей деятельностью отделов, что включает в себя и программное обеспечение, которое выполняет основную функцию оптимизации. Исходя из описанного выше, целью работы является оптимизация и частичная автоматизация процесса страхования грузоперевозок, за счет внедрения технологии BPM, обеспечение удобного мониторинга и контроля исполнения подпроцессов страхования сотрудниками компании. Для достижения заданной цели в работе поставлены следующие задачи: 1. ознакомление с требованиями компании-заказчика, составление плана работ; 2. реализация логики процесса автоматизации страхования грузов; 3. реализация интерфейса пользователя для удобного взаимодействия с системой; 5

4. тестирование разработанного программного продукта. В первой главе работы приведено краткое описание процесса страхования грузоперевозок, определены проблемы в оптимизации как предметной области, так и разработки программного обеспечения в целом. Во второй главе происходит обзор современных подходов к разработке ПО, определены преимущества использования технологии BPM для автоматизации бизнес-процессов, а также проведен сравнительный анализ существующих платформ разработки для реализации поставленной задачи. В третьей главе представлено описание процесса реализации программного продукта: определение требований к разрабатываемой системе, описание архитектуры подпроцессов страхования, логика реализации, а также описание интерфейса взаимодействия с продуктом. Структура и объем работы: ВКР выполнена на 52 странице машинописного текста, состоит из введения, трех глав, заключения и приложения, содержит 22 рисунков, 1 таблицы и 1 приложение на 2 страницах. 6

ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И ПОСТАНОВКА ЗАДАЧИ 1.1 Обзор предметной области страхования грузоперевозок В силу динамически развивающегося взаимодействия между физическими и юридическими лицами, представляющими разные категории бизнеса, появляются необходимость и обязательства страхования объектов данных взаимоотношений. Процесс страхования на сегодняшний день является неотъемлемым и часто обязательным инструментом урегулирования современных взаимоотношений между лицами и структурами задействованными в различного рода бизнесдеятельности. Этот элемент рыночной экономики нормализует и устанавливает правила ведения дел между партнерами и контрагентами. Это позволяет на этапах определения договоренностей по сделкам исключить возможные негативные факторы и форс-мажоры. В публичных цифровых источниках, основанных на профильной литературе можно найти такое описание страхования и процессов, связанных с ним: страхование – отношения по защите интересов физических и юридических лиц, РФ, субъектов РФ и муниципальных образований при наступлении определенных страховых случаев за счет денежных фондов, формируемых страховщиками из уплаченных страховых премий (страховых взносов), а также за счет иных средств страховщиков. При этом страхуемые интересы должны отвечать следующим требованиям: 1. определенные интересы должны быть субъективными; 2. возможность страхования данных интересов должна быть юридически признана; 3. страхуемый интерес не должен противоречить ст. 928 ГК РФ. 7

Целью организации страхового дела является обеспечение защиты имущественных интересов физических и юридических лиц, РФ, субъектов РФ и муниципальных образований при наступлении страховых случаев. Задачами организации страхового дела являются: 1. проведение единой государственной политики в сфере страхования; 2. установление принципов страхования и формирование механизмов страхования, обеспечивающих экономическую безопасность граждан и хозяйствующих субъектов на территории РФ. Признаки страховых отношений: 1. возмещение денежной суммы при наступлении определенных событий; 2. случайность наступления событий, при которых выплачивается определенная договором сумма; 3. наличие интереса (имущественного или неимущественного) у одного из участников отношений, защита которого и обеспечивается уплатой установленной денежной суммы; 4. платность услуги по предоставлению защиты; 5. наличие специально формируемых денежных фондов, за счет средств, которых и обеспечивается защита [1]. В целом структура взаимодействия страховых компаний и их клиентов представлена на рис. 1.1. 8

Рис. 1.1 Схема взаимодействия страховых компаний и их клиентов В данной работе, как было сказано во введении, направлением страхования, для автоматизации процесса которого реализован программный продукт – личный кабинет, является страхование грузоперевозок для юридических лиц. Компания-заказчик определяет для себя это направление, как наиболее перспективное и финансово выгодное. Страхование имущественных интересов грузовладельца (иными словами, страхование грузов) предусматривает возмещение тех убытков, которые были вызваны повреждением или полной утратой груза (товара), перевозимого посредством различных видов транспорта. Страхование грузов – это один из видов имущественного страхования, который имеет целью полную или же частичную защиту всех имущественных интересов владельцев грузов на случай наступления убытков, вызванных различного рода происшествиями (страховыми событиями) в процессе транспортировки груза. Страхование грузов в профессиональной лексике страховщиков часто называется КАРГО (Cargo – Груз – перемещаемый между пунктом отправки и пунктом доставки товар), тогда как страхование самих средств транспорта – КАСКО (Casco – Шлем – страхование средств транспорта (автомобилей, судов, самолётов, вагонов) от ущерба, хищения или угона). В Российской Федерации страхование грузов 9

является одним из самых востребованных и стабильных видов страхования, который характеризуется достаточно слабой изменчивостью основных показателей из года в год. Страхование грузов является одним из наиболее распространенных видов страховых операций. Страхователями в этом виде страхования могут выступать любые юридические и физические лица, которые могут являться как грузоотправителями, так и грузополучателями. Кто конкретно заключает договор страхования грузов, покупатель или продавец, зависит от условий поставки продукции, а также обусловленных этими же самыми условиями юридических и экономических взаимоотношений данных сторон. Риск гибели или порчи товаров, в зависимости от условий сделки по страхованию, переходит от продавца к покупателю: при выдаче продукции со склада продавца, в процессе доставки ее на склад (или в порт) перевозчика, при погрузке в вагон (в автомобиль, на судно или в самолет), при разгрузке продукции на станции назначения. Таким образом, прекрасно понятно, что риск понести потери, преимущественно, лежит именно на покупателе, поэтому вполне естественно, что он прежде всего заинтересован в страховании своих грузов. Однако, договор страхования грузоперевозок может быть заключенным и продавцом (например, по просьбе покупателя или с его согласия) с включением всех страховых премий в стоимость доставляемого покупателю товара [2]. Основными целями, которые преследует компания-заказчик программного обеспечения являются те, которые позволяют принимать на страхование разнообразные грузы в любой точке России и мира, а также существенно сокращать время на возмещение ущерба. Клиенты СК должны иметь возможность обратиться в филиал компании в любом регионе России для выяснения обстоятельств прохождения груза по маршруту, а также воспользоваться услугой по перекрестному осмотру груза. Для разных видов транспорта СК должна формировать оптимальную программу страхования с 10

точки зрения надежности защиты перевозимых грузов и оптимизации затрат клиентов. Текущая разработка обеспечивает частичную автоматизацию и оптимизацию работы отделов, внутри которых производится сбор и обработка всех необходимых прохождения всех структурирования, данных процесса соответствующих сохраняются в грузоперевозок, внутренних базах данных которые этапов для после анализа и последующего использования внутри СК и предоставления клиенту в виде определенного рода отчетов, дающих ему понимание статуса грузоперевозки и качества состояния груза. 1.2 Исследование проблем в оптимизации разработки программного обеспечения Современными проблемами в оптимизации и проектировании ПО являются: 1. выделение необходимых этапов разработки; 2. определение количества участвующих сотрудников; 3. достижение договоренности сторон по поводу стоимости работ; 4. согласование минимально необходимого функционала для вывода в продуктивное использование работоспособного продукта; 5. определение условий поддержки реализованного приложения. Далее подробно рассмотрен каждый из вышеперечисленных пунктов. Выделение необходимых этапов разработки и определение количества участвующих сотрудников подразумевает такие сложности как: 1. согласование непосредственно количества этапов; 2. установление объема необходимых ресурсов; 3. продолжительность каждого из этапов. 11

В зависимости от установленного количества этапов, определяется, какое время и какое количество специалистов будет задействовано в процессе. И, с учетом занятости и квалификации сотрудников, определяется продолжительность каждого из этапов. За счет того, что парадигма разработки BPM имеет проработанную и налаженную структуру, реализация автоматизации процессов значительно упрощается за счет заведомо известных разработчику минимально-необходимых ресурсов для выполнения той или иной прикладной задачи. Достижение договоренности сторон по поводу стоимости работ упрощается за счет того, что концепция BPM подразумевает наличие унифицированных, заранее разработанных шаблонов, реализующих автоматизацию бизнес-процессов разных сфер социальной деятельности (медицина, банковский сектор, страхование, производство и высокие технологии, энергетика и правительственный сектор). На этапе аналитики любого программного продукта, как правило, определяется минимально работоспособный набор функций, который можно вывести в продуктивное использование. За счет того, что весь необходимый функционал, в силу особенности парадигмы BPM, разбивается на набор атомарных функций или бизнес-процессов, которые четко выявляются на этапе планирования, по всем требованиям гораздо проще устанавливаются договоренности между заинтересованными сторонами. При определении условий поддержки разрабатываемого продукта, одним из вариантов размещения приложения могут быть использованы облачные технологии, которые реализованы ведущими компаниями, использующими в своих системах разработки парадигму BPM. За счет этого исключается необходимость во внедрении в рабочий процесс специалистов в области системного администрирования, за исключением случаев запуска программного продукта на серверах клиента или заказчика. В компетенции архитектора, который является разработчиком по правилам BPM, входит администрирование 12

предоставляемой облачной технологии. Это еще одно из условий, удешевляющих стоимость разработки. В результате, уже на этапе анализа программного продукта происходит построение архитектуры приложения и исключается этап архитектурного проектирования с участием отдельных специалистов. Все обособленные внутренние сервисы программного продукта уже заранее смоделированы в процессе планирования. Большинство из этих процессов и функций необходимо лишь настраивать и параметризировать. Тем самым уже на ранних этапах минимизируются временные и человеческие ресурсы, что во всех смыслах удешевляет разработку. Это является серьезным плюсом при выборе именно такого подхода. Также с учетом поэтапного описания бизнес-процессов на уровне бизнес-аналитики, который происходит в тесной взаимосвязи с разработчиками, замещается и в некотором смысле интерпретируется такой современный подход разработки ПО как BDD (Behavior Driven Development), реализуемый технологией Gherkin. Этот подход предполагает разработку функциональных и тестовых сценариев аналитиками, либо специалистами по тестированию на этапе, предшествующем разработке [3]. Сценарий представляет собой набор шагов и действий, описанных на естественном языке. В итоге реальный процесс разработки, при условии использования BPM, выглядит так: 1. бизнес-аналитика; 2. разработка; 3. тестирование; 4. внедрение; 5. поддержка. Этот подход, как уже говорилось, усложняет и увеличивает продолжительность процесса бизнес аналитики, но в целом удешевляет и упрощает весь жизненный цикл получаемого программного продукта. 13

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

ГЛАВА 2. ВЫБОР ПРОГРАММНЫХ СРЕДСТВ ДЛЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Выбор программных средств реализации автоматизации различных процессов, обусловлен, в первую очередь, быстрыми и динамическими развитием и изменением этих процессов. Разработчикам, выполняющим соответствующие заказы на сегодняшний день необходимы инструменты, способные максимально быстро реализовывать все этапы разработки программного обеспечения и являющиеся недорогими в смысле затраты ресурсов на их приобретение и их внедрения в свою инфраструктуру и инфраструктуру заказчика. 2.1 Сравнение современных походов разработки программных продуктов На рис. 2.1 изображена общая схема жизненного цикла программного обеспечения с точки зрения бизнес аналитики. Рис. 2.1 Цикл управления 15

Для понимания преимуществ применения концепций BPM необходимо провести её сравнительный анализ с современными подходами к разработке ПО. Сегодня имеется два основных подхода: процессный и функциональный. К процессному относится парадигма BPM. Процессный подход к управлению предприятием можно считать базовым при интегрировании предприятия. При этом подходе объектом управления выступает определенная деятельность на предприятии – процесс, который можно определить как ряд взаимосвязанных видов деятельности, характеризующихся потреблением ресурсов (вход процесса) и дающих определенный результат (выход процесса). Процессы проходят через все подразделения, вовлекая все службы предприятия, и ориентируются на конечный результат – увеличение стоимости бизнеса. Управляя процессами, имеющими свои цели, можно добиться высокой эффективной деятельности с помощью хорошо налаженных горизонтальных связей в вертикальной структуре управления предприятием. Процессный подход – это выход на продуктивную идею внутренних поставщиков и потребителей, так как реальная деятельность, приносящая добавленную стоимость, не осуществляется отдельными элементами функциональной иерархии, а пронизывает предприятие в виде совокупности процессов. Процессный подход позволяет: 1. учитывать такие важные моменты, как ориентация на конечный результат, заинтересованность каждого исполнителя в повышении качества не только конечного продукта, но и своей работы; 2. быстро реагировать на изменения условий внешних и внутренних факторов; 3. оптимизировать обмен информацией подразделениями; 16 между функциональными

4. реализовать важную черту менеджмента качества встраивание контроля качества в процесс вместо контроля качества готовой продукции. При реализации процессного подхода исполнители обладают большими полномочиями, увеличивается их роль, самостоятельность и, следовательно, отдача и удовлетворение трудом. Руководители же освобождаются от текущих оперативных вопросов и полностью концентрируются на решении стратегических, системных вопросов. При функциональном подходе предприятие рассматривается как механизм, обладающий набором функций, которые распределяются среди подразделений и выполняются сотрудниками предприятия. Они выполняют узкоспециализированные задачи, не работая на достижение миссии предприятия. Структурные подразделения предприятия взаимодействуют между собой и передают друг другу управляющие воздействия, что порождает различного рода разногласия: конфликты интересов, конфликты бюджетов и т.п. Основные недостатки функционального подхода заключаются в следующем: 1. при функционально структурированной организации отсутствует заинтересованность сотрудников в конечном результате. Чаще всего видение происходящего работниками не выходит за рамки своих подразделений, они не ориентированы на конечные цели предприятия, на удовлетворение потребностей покупателя; 2. значительная часть реальных рабочих процессов на предприятии включает множество функций, т.е. выходит за рамки отдельных подразделений. Однако в функционально ориентированных структурах обмен информацией между различными подразделениями чрезмерно усложнен из-за ее вертикальной иерархичности, что приводит к большим накладным расходам, неоправданно длительным срокам принятия управленческих решений; 17

3. большая часть управленческого времени, необходимого воздействия на для осуществления производственный процесс, затрачивается на взаимоотношения служб, и оно значительно больше, чем время на реализацию самого решения. Это приводит к тому, что реакция на возмущающее воздействие идет с неоправданно большим опозданием. По этим причинам общеизвестные способы совершенствования функциональной системы управления предприятием, например, изменение структуры предприятия, сокращение численности сотрудников, внедрение компьютерных информационных систем управления предприятием, попытки применения систем качества на базе ISO 9000 малоэффективны, а в некоторых случаях даже вредны. Поэтому кардинальное изменение ситуации на предприятии без изменения принципов управления не представляется возможным [4]. При интеграции систем управления предприятием необходимо заменить авторитарный стиль руководства на демократический. Одним из факторов развития системы управления от бюрократической модели, являющейся строго регламентированной системой, к динамической модели является децентрализация управления, которая заключается в делегировании широких полномочий нижестоящим функциональному уровням, наполнению что деятельности способствует лучшему менеджеров. Практика децентрализации в структурах управления позволила выявить множество преимуществ. Во-первых, она способствует активизации профессиональных навыков руководителей, что усиливает их ответственность за принятие решений. Во-вторых, децентрализованная структура управления развивает соперничество на предприятии, создает атмосферу конкуренции. В-третьих, в такой структуре у руководителя больше возможностей проявить самостоятельность и увидеть свой вклад в решение проблем, что положительно сказывается на результатах деятельности предприятия в целом. 18

Децентрализацию на предприятии не следует воспринимать буквально. В каждой из организаций, помимо функций, напрямую связанных с выполнением ее миссии, существует множество процессов по обеспечению основной деятельности: контроль качества, логистика, учет финансово-хозяйственной деятельности, компьютерное, информационное и хозяйственное обслуживание производственного процесса. Сравнительная характеристика функционального и процессного подходов представлена в таблице 2.1. Таблица 2.1 Сравнительная характеристика существующих подходов разработки программный продуктов Критерий Достоинства Недостатки Процессный Функциональный 1) ориентация на конечный результат; 2) достижение высокой эффективности деятельности; 3) гибкость реагирования на внешние и внутренние изменения; 4) контроль качества процесса, а не конечного продукта; 5) мотивация; 6) оперативность; 7) демократическая система управления; 8) ориентация на последующую интеграцию с системами компаний-партнеров, т.е. упрощение потенциального взаимодействия с внешними системами. 1) взаимозависимость лиц, принимающих решения. 19 1) бесконфликтный процесс принятия решений, исключающий взаимозависимость лиц, принимающих решения. 1) отсутствие заинтересованности работников в конечном результате, они не ориентированы на целевые задачи предприятия; 2) усложнен обмен информацией между подразделениями, что приводит к большим накладным расходам, длительным срокам выработки управленческих решений; 3) требуется много времени для реализации управленческого воздействия на производственный процесс;

4) авторитарное управление; 5) они выполняют узкоспециализированные задачи, не работая на достижение миссии предприятия. Из сравнительного анализа функционального и процессного подходов видно, что на сегодняшний день средства разработки должны максимально практично реализовывать автоматизацию целых процессов, а не отдельных функций предприятия. Процессный подход также может быть реализован в рамках разработки микро-сервисной архитектуры программных продуктов, которая может быть разработана средствами практически любых языков, используемых в различных IDE, но при этом в отличии от BPM-систем разработки у всех предполагаемых IDE нет в наличии такого количества заранее смоделированных и унифицированных шаблонов бизнес-процессов. 2.2 Преимущества использования BPM-систем в разработке корпоративного программного обеспечения Текущее положение дел на рынке разработки программного обеспечения говорит о том, что применение BPM систем в автоматизации работы предприятия является прогрессивным этапом в процессе разработки ПО в целом. И эти новшества отражаются и в организации структуры работы принимающих предприятий. Многие специалисты подтверждают такую тенденцию, отмечая это в своей практике. «Ключевой потенциал при внедрении BPMS (Business Process Management Systems) реализуется не через поддержку деятельности сотрудников предприятия, а через модификацию самого бизнес-процесса, которая всегда происходит при его автоматизации. В нашей практике не было случая, когда бы процесс при его переносе в BPMS оставался неизменным», – отмечает Василий 20

Анфиногентов, директор отделения автоматизации деловых процессов компании «ФОРС – Центр разработки». [5] При разработке продукта, который описан в данной работе пришлось столкнутся с абсолютно такой же особенностью внедрения системы в работу СК. Первая особенность, которая в некотором смысле является минусом в разработке ПО, это написание кода «с нуля». Приложение, написанное средствами системы BPM, представляет собой некий конструктор с заранее заготовленным основанием, в котором имеются все необходимые инструменты для реализации любых процессов и функций, интеграций и хранения данных. Также компания-разработчик за счет использования BPM-систем нивелирует проблему понимания старых наработок по проектам новыми сотрудниками. Специалисту нет необходимости разбираться с чужим кодом, архитектурой классов и структурами хранения данных. Так как выбранный процессный подход разработки подразумевает унифицированную архитектуру и требует от специалиста, участвующего в разработке, преимущественно лишь знания бизнес-процессов, автоматизированных в рамках проекта, в котором он задействован. Если взять в расчет такой важный момент как оптимизация затрат ресурсов компании в целом, то внедрение в разработку программных продуктов BPMсистемы является серьезным шагом к оптимизации объемов работ по разработке и количества задействованных сотрудников. Как упоминалось ранее, в силу специфики выбранного подхода, при организации различных жизненных циклов разрабатываемого приложения уменьшается количество необходимых специалистов для решения поставленных задач. С учетом цельной архитектуры, внутри которой все процессы соответствующих отделов предприятия являются легко интегрируемыми друг с другом внутренними инструментами BPM-системы разработки, отпадает необходимость в использовании таких тяжелых системных решений, как интеграционные шины, которые являются сложными структурами, требуют 21

обслуживания высоко-профильных специалистов и достаточно большого объема памяти для расположения на серверах компаний. На рис. 2.2 изображены основные цели и возможности, преследуемые концепцией BPM. Рис. 2.2 Цели и возможности BPM 1) Model – оптимизация моделирования; 2) Design – функционально удобная разработка дизайна; 3) Optimize – оптимизация имеющихся бизнес-процессов; 4) Execute – исполнение имеющихся бизнес-процессов; 5) Monitor – мониторинг процессов и в целом деятельности организаций. Все вышеперечисленные пункты заключают в себе основные требования современного бизнеса к современным управления. 22 автоматизированным системам

2.3 Обзор и сравнение с аналогами платформы разработки Pega BPM 7.3 Компанию Pega в 1983 году основал Алан Трефлер (Alan Trefler), возглавляющий ее по сей день. Алан – заядлый шахматист, и не случайно в логотипе Pegasystems присутствует силуэт шахматного коня (Рис. 2.3). Рисунок 2.3 Логотип платформы Pega BPM В 1996 году компания вышла на биржу (NASDAQ: PEGA) и вошла в лидерские списки по темам программного обеспечения для ВРМ и CRM. За 10 лет (2005-2015 гг.) оборот компании вырос более, чем в 10 раз [6]. В целом, на рынке существует большое количество BPM платформ, которые предоставляют возможность оптимизировать работу предприятия и повысить качество управленческих решений. По версии аналитического центра Gartner, в число лидеров «магического квадрата» на протяжении нескольких лет входят продукты компаний: Pegasystems, Appian и IBM (Рис. 2.4). 23

Рис. 2.4 Магический квадрат Gartner BPM по результатам 2016 года Лидерство Pega на рынке BPM обеспечивает наиболее функционально полная в отрасли единая платформа для построения решений по интеллектуальному управлению бизнес-процессами. Ее функциональность включает динамическое управление кейсами (Case management) и бизнесправилами, разработку мобильных приложений, отчетность, безопасность, интеграцию, прогностическую и адаптивную аналитику. В России заказчиками Pega уже стали «Альфа-Банк» и Сбербанк, где выполняются большие проекты по автоматизации сквозных бизнес-процессов. В целом, реализованные проекты на Pega отличаются масштабом и функциональной направленностью [7]. Среди наиболее примечательных можно отметить: 1. открытие счетов для клиентов малого и среднего бизнеса; 2. розничный CRM; 3. Call Center для розничного блока; 4. управление входящими маркетинговыми кампаниями; 24

5. продажа и обеспечение кредитных карт; 6. автоматизация деятельности правового департамента; 7. расчет премий для сотрудников розничного подразделения и интеграция с SAP; 8. смена клиентского менеджера в корпоративном сегменте; 9. автоматизация процессов миддл-офиса; 10. интеллектуальная маршрутизация задач для андеррайтеров. По словам Сергея Лобова – коммерческого директора Pegasystems Россия – «Спектр применения платформы практически безграничен. Опыт реализованных проектов также показывает, что первых существенных результатов можно достичь в течение 90 дней после старта проекта». Pega BPM является признанным лидером в области управления бизнеспроцессами в режиме реального времени, а также управления взаимоотношениями с клиентами с помощью многоканальных приложений. Pega BPM предназначена для повышения эффективности бизнес-процессов, их визуализации и обеспечении адаптивности. Запатентованная многослойная архитектура Pega, известная как Situation Layer Cake, позволяет создавать корпоративные приложения, которые будут быстро адаптироваться к различным сегментам рынка, локациям и производственным линиям. Функционал данной платформы включает динамическое моделирование кейсов и бизнес-правил, разработку мобильных приложений, построение отчетов, поддержку интеграции со внешними системами, а также, прогностическую и адаптивную аналитику. Данная платформа состоит из трех основных компонентов (рис. 2.5): средство проектирования процессов (Pegasystems Designer Studio), исполнение процессов (Pegasystems SOA-based Server) и базы данных бизнес-правил (PegaRules Database) К преимуществам данной платформы можно отнести применение структуры наследования, для повторного использования элементов приложения, что позволяет не только поставлять, но и создавать собственные приложения, 25

которые можно использовать по всей структуре организации. Также помимо типичных возможностей BPM систем, Pega включает в себя возможность интеграции, сопоставления и кэширования данных, что облегчает их использование в процессах и отчетах. Не мало важным является и то, что платформа включает в себя возможность управления требованиями и имеет встроенную методологии реализации (Direct Capture of Objectives, DCO). Ценность платформы заключается в создании критически важных для бизнеса приложений, которые могу изменятся и улучшаться в течение многих лет [8]. Еще одним очень важным для клиентов и представителей заказчика преимуществом, является функция авто-документирования, которая работает таким образом: при проектировании каждого бизнес-процесса системой предоставляется возможность его текстового описания. В последствии, имея на руках готовый проект, мы можем выполнить выгрузку документа, которой предшествует структурированный сбор системой в этом документе всех описаний спроектированных бизнес-процессов и блок-схем их жизненного цикла. Рис. 2.5 Схема взаимодействия компонентов Pega BPM Платформа располагает готовыми решениями для обеспечения взаимодействия с сотрудниками клиентов и партнеров. Каналы взаимодействия: 1. контакт-центр; 2. email; 3. web-Портал; 4. web-Чат; 5. web-Нотификации. 26

Также с учетом наличия шаблонов сервисов интеграции (REST-api, SOAPapi, JMS и т.д.) можно взаимодействовать с такими порталами оповещений как sms.ru и прочими. IBM WebSphere Lombardi – это простое в использовании BPM-решение, которое представляет собой единую, высокопроизводительную и устойчивую систему, обеспечивающую создание и администрирование приложений для реализации бизнес-процессов. Общая архитектура моделирования обеспечивает взаимосвязь между бизнес-подразделениями и ИТ-службами. Платформа состоит из семи основных компонентов (Рис. 2.6): два средства проектирования процессов (Process Designer, Integration Designer), единое хранилище (Process Center), Process Portal, Process Coach, исполнение процесса (Process Server), хранилище данных показателей производительности (Performance Data Warehouse). Process Center объединяет в себе все компоненты в единой среде проектирования и репозитории активов. К преимуществам данной платформы можно отнести подход использования центрального хранилища данных, что упрощает управление и администрирование приложений. Большой набор API-интерфейсов позволяет легко интегрироваться с другими продуктами и автоматизировать жизненный цикл бизнес-процесса. Рис. 2.6 Схема взаимодействия компонентов IBM WebSphere Lombardi BPM 27

Appian BPM – это решение для управления бизнес-процессами, которое предоставляет автоматизацию внутренних процессов приложения, облегчает управление и мониторинг выполняемых задач. Все данные, процессы и документы находятся в одной среде и интегрированы через простой социальный интерфейс. Appian предлагают решения, которые быстро создаются, имеют возможность повторного использования, а комплексная обработка событий позволяет отслеживать, анализировать и обрабатывать бизнес-события [9]. Платформа состоит из пяти основных компонентов: дизайнер процессов (Process Designer), исполнение процессов (Appian Server), Process Portal, Process Center, Database (рис. 2.7) Особенностью платформы Appian является ориентация на бизнеспользователей, за что собственно бизнес-пользователи и восхищаются данной платформой. Центральным элементом данной платформы является социальное сотрудничество, что является не инновационным решением, но довольно уникальным. В Appian легко создавать пользовательские порталы, имеются предустановленные интеграционные решения для соединения со внешними системами и предоставляются инструменты для быстрого создания отчетов. Рис. 2.7 Схема взаимодействия компонентов Appian BPM В целом, все представленные продукты отвечают стандартам интеллектуального управления бизнес-процессами. Они едины, имеют все необходимые функции и методы для реализации бизнес-приложений и 28

оптимизации их работы. Каждый поставщик делает ставку на определенные особенности своего продукта и в соответствии с этим выбор оптимального инструмента для организации, которая хочет внедрить BPM-решение, будет зависеть он фокусировки его бизнеса. Так, допустим, решение Pega BPM, будет верным для большой компании, которая планирует развиваться и масштабировать свою деятельность на протяжении многих лет. IBM BPM больше подойдет для организации со сложной ИТ-структурой, а соответственно и сложными ИТ-требованиями. А Appian BPM станет хорошим решением для компаний, которые ищут быстрое решение определенных проблем рабочего процесса. 2.4. Выводы В следствии проведения сравнительного анализа современных подходов и систем разработки программного обеспечения было выявлено, что концепция BPM и платформа Pega 7.3 отвечают всем современным стандартам и требованиям разработки программного обеспечения, что определяет важность их наличия на современном рынке автоматизации. 29

ГЛАВА 3. ПРОЕКТИРОВАНИЕ И ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ЛИЧНОГО КАБИНЕТА СТРАХОВОЙ КОМПАНИИ 3.1 Требования к программному продукту В процессе разработки приложения со стороны компании-заказчика были выставлены требования к параметрам и возможностям системы: 1. обеспечить 10 000 уникальный пользователей - сотрудников партнеров, внутренних пользователей; 2. организовать 30% одновременно работающих пользователей; 3. обеспечить 1000 Компаний-партнеров по 10 сотрудников в каждой; 4. поддерживать максимальное число договоров на одно юридическое лицо – 100 шт; 5. поддерживать максимальное число генеральных договор на компаниюпартнера 2-3 тыс; 6. учитывать число Деклараций на один генеральный договор около 15 000 в год. 3.2 Требования к аппаратной части Рекомендации к аппаратной части продукта получены от профильного специалиста со стороны компании-исполнителя. На основе выдвинутых заказчиком требований к времени отклика и времени восстановления после сбоя (доступность сервиса не ниже 99,0%). Были подобранны несколько вариантов архитектуры аппаратного обеспечения, удовлетворяющих данным требованиям: 1. Виртуальные сервера / Физические сервера. Кластеризация осуществляется средствами PEGA. При двух-узловой конфигурации: время восстановления в случае одиночного сбоя оборудования – 0 30

минут, в случае выхода двух узлов - 6 часов. Отказоустойчивость повышается при добавлении узла в кластер; 2. Виртуальные сервера. Время восстановления в случае сбоя оборудования – 20 минут, связано с запуском виртуальной машины на базе другого сетевого узла (сервера) VMWare в кластере; 3. Кластерные системы на базе технологии Microsoft Failover Cluster. При сбое оборудования время восстановления – 10 минут при равных мощностях обоих узлов кластера. Это связано с перемещением ресурсов на другой узел. На этапе аналитики был выбран первый вариант. По причине легкого масштабирования, простоты технологии и экономии на оплате лицензионных соглашений. Продуктивный сервер: 1. Серверная подсистема: 2 сетевых узла по 24 ядра (Xeon e5)/32гб ОЗУ; 2. Подсистема хранения данных: Raid1 или выше, 2 серверных диска + 1 в режиме Standby не менее 146 Гб. Сервер разработки: 1. Серверная подсистема: 2 ядра/8гб ОЗУ; 2. Подсистема хранения данных: требований нет. Тестовый сервер для нагрузочного тестирования: 1. Серверная подсистема: 1 сетевой узел 24 ядра (Xeon e5)/32гб ОЗУ; 2. Подсистема хранения данных: Raid1 или выше, 2 серверных диска не менее 146 Гб. 31

3.3 Архитектура процессов по страхованию грузов 3.3.1 Описание бизнес-логики личного кабинета страховой компании Реализуемый бизнес-процесс регистрации заявки на Декларацию подразумевает участие 3-х основных ролей пользователей (рис. 3.1): 1. Клиент – Создание/просмотр заявок на создание Декларации; 2. Сотрудник ОСГ – валидация заявок клиента; 3. Сотрудник ДПМ – проверка рисков по перевозкам, указанных в Декларации. Рис. 3.1 Участники бизнес-процесса регистрации заявки на Декларацию Предусловием к выполнению данного процесса, являются: заключение со страховой компанией генерального договора о предоставлении услуг страхования ответственности перевозчика и прохождение процесса авторизации на сайте ЛК. Сам алгоритм регистрации заявки на Декларацию можно описать следующим образом (рис. 3.2): 32

Рис. 3.2 Описание бизнес-процесса заявки на Декларацию Шаг 1. Выбрать договор – получение информации о генеральных договорах-Выбор генерального договора. Шаг 2. Завести заявку на Декларацию – заполнение формы Декларации / отправки, включая проверку по ФЛК. Возможность получения ПФ Декларации. Шаг 3.1. Проверить Заявку – сотрудник ОСГ заходит в ЛК и проверяет реквизиты заявки. Шаг 3.2. Запросить проверку перевозчика – сотрудник ОСГ направляет запрос в ДПМ на предмет проверки перевозчиков, указанных в Декларации. Шаг 3.2.1. Проверить перевозчика 1. Сотрудник ДПМ заходит в ЛК кабинет и просматривает данные заявки в части перевозчика. 2. На основании этих данных вручную заполняет форму во внутренней закрытой системе проверки перевозчиков и получает ответ. 3. В ЛК заполняет рекомендации и отправляет ответ Сотруднику ОСГ. Шаг 4. Принять решение по заявке – сотрудник ОСГ принимает решение по заявке, с учетом результата проверки перевозчиков. 33

Шаг 5. Печать полиса – если Заявка Акцептована, Клиент имеет возможность распечатать полис на основании данных Декларации в соответствии с формой Грузы-Заявка. Шаг 6. Уведомить о необходимости оформить новый договор – если Заявка отклонена, то Клиент при следующем входе в Личный кабинет должен увидеть соответствующее уведомление, о том, что Заявка не удовлетворяет условиям генерального договора, и необходимо заключить новый договор в офисе компании. Шаг 6.1 Печать разового полиса – клиент имеет возможность распечатать разовый полис в соответствии с формой Грузы-Разовый полис. На основе существующих Деклараций о грузоперевозках, клиенту предоставляется Бордеро для осуществления оплаты. Данный бизнес-процесс подразумевает участие 3-х основных ролей (рис. 3.3): 1. Клиент – просмотр/согласование Бордеро, просмотр реквизитов счетов; 2. Сотрудник ОСГ – согласование Бордеро на основании Декларации клиента, создание заявок на заведение Бордеро во внутреннюю систему учета; 3. Сотрудник отдела конвертации – заведение Бордеро во внутреннюю систему учета. Рис. 3.3 Участники бизнес-процесса формирования и оплаты Бордеро 34

Предусловием к выполнению данного процесса, являются: заключение с компанией генерального договора о предоставлении услуг страхования ответственности перевозчика, наступление окончания отчетного периода и заведение не менее одной Декларации за отчетный период, которая была согласована со стороны СК. Алгоритм формирования и оплаты Бордеро можно описать следующим образом (рис. 3.4): Рис. 3.4 Описание бизнес-процесса формирования и оплаты Бордеро Шаг 1. Создать/редактировать Бордеро – сотрудник ОСГ заходит в ЛК, выбирает клиента, задает отчетный период и формирует Бордеро и отправляет клиенту на согласование. Шаг 2. Согласовать Бордеро – клиент в ЛК просматривает Бордеро и принимает решение о согласовании. Если Бордеро не согласовано, то документ возвращается на редактирование сотруднику ОСГ, происходит возврат к Шагу 1. 35

Шаг 3.1. Ввести реквизиты счета – сотрудник ОСГ создает счет в СИП , затем загружает счет (документ формата Excel) в ЛК, после чего уходит нотификация клиенту, о том, что выставлен счет на оплату. Шаг 3.2. Получить реквизиты счета – клиент в ЛК имеет возможность просмотреть реквизиты счета, а также распечатать печатную форму счета. Шаг 3.3. Оплата счета – клиент оплачивает счет. Информация об оплате отражается во внутренних системах СК. Шаг 4.1. Завести заявку на конвертацию Бордеро – сотрудник ОСГ заходит в ЛК формирует и выгружает Excel-файл Бордеро. Затем направляет запрос на почтовый ящик компании, приложив указанный файл. При этом формируется заявка в ОЦДеск. Шаг 4.2. Ввод Бордеро во внутреннюю систему учета – сотрудник Отдела конвертации на основании заявки и полученного файла Бордеро заводит Бордеро в систему учета. При наступлении страхового события клиент должен оформить заявку на его регистрацию в ЛК. Для реализации данного бизнес-процесса предполагается участие непосредственно двух главных ролей: 1. Клиент – работа с извещениями и заявлениями о страховом событии 2. Сотрудник компании – обработка заявлений клиента Предусловием к выполнению данного процесса, являются: заключение с компанией генерального договора о предоставлении услуг страхования ответственности перевозчика и заведение не менее одной Декларации за отчетный период, которая была согласована со стороны СК, а также была произведена оплата счета-Бордеро. Алгоритм регистрации наступления страхового события можно описать следующим образом (рис. 3.5): 36

Рис. 3.5 Описание бизнес-процесса регистрации наступления страхового события Шаг 1. Выбор Декларации – клиент в ЛК выбирает Договор/ Декларацию. Шаг 2. Заполнение формы извещения – клиент в ЛК заполняет форму извещения о наступлении страхового события с указанием суммы ущерба. Шаг 2.1. Печать извещения – клиент имеет возможность распечатать форму извещения. Шаг 2.2. Подпись и сканирование извещения – клиент подписывает распечатанное извещение и сканирует документ. Шаг 3. Отправка извещения – клиент, заполнив форму извещения (с возможностью загрузки скана подписанного документа) нажимает кнопку отправки заявления. Система осуществляет отправку извещения в ОИСУУ. Шаг 4. Создать убыток – если убыток по указанной Декларации и дате уже был ранее заведен в ОИСУУ сотрудником ВСК, то извещение прикрепляется к этому убытку, иначе создается убыток с присвоением номера. Шаг 5. Получить номер убытка – в ЛК отображается информация об убытке и его начальный статус. 37

3.3.2 Кейс генерального договора Генеральный договор является основным документом, который регулирует взаимоотношения между клиентом и страховой компанией. По условиям бизнес требований компании-заказчика, все договоры хранятся в учетной системе, с которой производится интеграция разрабатываемой системы. Для получения списка доступных договоров и их объектов клиенту нужно авторизоваться под своей учетной записью. При авторизации происходит автоматический запрос к системе хранения данных по средствам REST-запросов. Входными данными является ID сотрудника определенной компании, исходными генеральные договоры и список прикрепленных объектов каждого договора: 1. заявки; 2. Декларации; 3. отчетные периоды; 4. Бордеро; 5. перевозчики; 6. страховые события; 7. жалобы. Жизненный цикл кейса договора выглядит следующим образом (рис. 3.6), первый этап – это получение детальной информации по договору и его объектам, с помощью REST-запросов к системе хранения данных. Вторым этапом является отображение полученной информации по договору и списки существующих объектов договора для дальнейшей работы с системой. Рис. 3.6 Жизненный цикл кейса генерального договора 38

3.3.3 Кейс регистрации заявки на Декларацию Декларация – это связанный с генеральным договором полис, содержащий детальную информацию об отгрузке застрахованного груза, который сопровождает груз от отправителя до получателя, и содержит такую информацию как: 1. полное наименование груза; 2. род упаковки; 3. выгодоприобретатель; 4. страховая сумма; 5. валюта; 6. пункты отправления, перегрузки (таможенного контроля) и назначения; 7. период страхования; 8. информацию по товарно-транспортной накладной; 9. наименование перевозчика и т.п. Жизненный цикл (рис. 3.7) данного кейса подразумевает несколько этапов: первый этап – это логирование запуска кейса, для возможности мониторинга действий клиента. Рис. 3.7 Жизненный цикл кейса заявки на регистрацию Декларации 39

Следующий этап подразумевает заполнение формы Декларации об отгрузке груза и подтверждение отправки на проверку сотрудникам СК. Третьим этапом является проверка Декларации, которая содержит два параллельных процесса, что позволяет производить работу над кейсом одновременно несколькими пользователями системы (в данном случае клиентом и сотрудниками СК). Первый процесс – это проверка самой Декларации, первым шагом которой, является проверка введенных пользователем реквизитов: при отправке формы клиентом, кейс поступает в рабочую корзину сотрудников ОСГ, свободный оператор берет в работу данный кейс и определяет правильность введенный данных. После чего, если данные верны кейс отправляется в рабочую группу сотрудников ДПМ, задачей которых является проверка перевозчика по внутренним базам данных и закрытым стоп-листам перевозчиков. Третий шаг, данного процесса подразумевает общую проверку представленной Декларации, с учетом проверенных реквизитов и рекомендаций от сотрудников ДПМ. Вторым процессом является отображение общей информации по Декларации и рабочего статуса кейса, данный процесс позволяет клиенту отслеживать статус своего запроса на регистрацию Декларации. В случае, если проверка пройдена успешно, кейс отправляется на шаг подтверждения Декларации и следом на шаг отображения краткой информации о Декларации и связанных с ней объектов. В противном случае, кейс отправляется на альтернативный шаг отклонения Декларации. 3.3.4 Кейс формирования и оплаты Бордеро Бордеро представляет собой сводный отчет, за определенный период времени по всем Декларациям осуществленным за выбранный промежуток времени: пол календарного месяца, календарный месяц. Жизненный цикл (рис. 3.8) состоит из 6-ти этапов: 40

Рис. 3.8 Жизненный цикл кейса формирования и оплаты Бордеро Первый этап, как и в предыдущем кейсе предназначен для логирования действий пользователя. Далее идет этап непосредственного формирования Бордеро, сотрудником страховой компании, а именно: выбор отчетного периода и составление самого отчета в виде таблицы с информацией об имеющихся Декларациях за выбранный промежуток времени. Третий этап предназначен для проведения согласования с клиентом образованного сводного отчета. Если клиент определил недочеты, он указывает их в отдельных полях формы и кейс отправляется на доработку сотруднику СК. Если же клиент согласен со всеми пунктами, он подтверждает правильность и кейс отправляется на четвертый этап. Следующим этапом проведения Бордеро, является создание и оплата полученного счета. Данный этап состоит из двух параллельных процессов, первым из которых является составление счета во внутренней системе компании и загрузки его в ЛК сотрудником СК. После уведомления клиента о том, что счет выставлен на оплату, он имеет возможность просмотреть реквизиты и загрузить документы, подтверждающие оплату. Вторым процессом является отображение 41

краткой информации по ходу обработки Бордеро, для обеспечения возможности отслеживания статуса выполнения кейса. Завершающим этапом является отправка данных на корпоративный e-mail компании, с помощью стандартного шаблона отправки электронных писем, для последующего ввода их во внутренние системы СК. 3.3.5 Кейс регистрации наступления страхового события Под страховым событием понимается событие, в результате наступления которого, для застрахованного лица вступают в силу обязательства по возмещению ущерба от страховой компании. Жизненный цикл кейса наступления страхового события (рис. 3.9), подразумевает следующие этапы: Рис. 3.9 Жизненный цикл кейса наступления страхового события Первым этапом, является этап выбора Декларации, при котором данные по Декларации передаются созданному страховому случаю. Также в этом этапе присутствует стандартный шаг логирования действий пользователя. Следующий этап подразумевает заполнение формы извещения о наступлении страхового события с возможностью выгрузки её печатной формы, для последующей загрузки подписанного клиентом скана извещения. 42

Третий этап предполагает отправку извещения во внутреннюю информационную систему, после чего происходит проверка наличия дубликата убытка по указанной Декларации. Если дубликат найден, то извещение прикрепляется к уже существующей записи в системе, в противном случае создается запись с присвоением уникального номера. Заключительный этап позволяет просматривать статус заявки и прослеживать данные об оплате или отказе в выплате. 3.4. Описание интерфейса пользователя Разработанная система использует Basic-аутентификацию пользователей, которая подразумевает передачу логина и пароля в незашифрованном виде, однако также используется протокол HTTPS, который нивелирует риски угрозы безопасности. На рис. 3.10 изображена главная страница входа в личный кабинет, которая наследующих этапах разработки будет стилизована под брендбук заказчика. Рис. 3.10 Страница аутентификации пользователя 43

После успешного прохождение аутентификации и авторизации клиента, ему предоставляется доступ к порталу личного кабинета, который имеет: шапку с логотипом компании, названием выбранного профиля страхования, строкой поиска по предоставленному порталу, а также кнопкой доступа к личному профилю клиента; боковую панель с меню приложения, которое подразумевает шесть основных пунктов и вкладку «Недавние», данная вкладка предоставляет доступ к недавно закрытым документам; основную зону для взаимодействия с системой и просмотра данных. Пункт меню «Главная» предоставляет доступ к главной странице личного кабинета клиента (рис. 3.11). Рис. 3.11 Главная страница личного кабинета – Генеральные договоры На данной странице представлены четыре вкладки с основными объектами ЛК. Первая и главная вкладка представляет таблицу заключенных Генеральных договоров пользователя. Вторая вкладка содержит список заявок на проверку перевозчика по закрытым базам данных и внутренним стоп-листам компании. Следующая предоставляет список заявок на возмещение убытков по предоставленным извещениям о страховом событии. И последняя содержит таблицу с заказанными отчетными документами. 44

В каждой из таблиц представлены такие поля, как: уникальный идентификатор (номер) документа, дата создания документа и его статус. Каждая из вкладок содержит функцию поиска того или иного документа по его уникальному идентификатору. Также по клику на уникальный идентификатор документа, можно открыть его. В зависимости от этапа его обработки будет выведено отображение его финальной стадии или промежуточные данные для проверки статуса обработки. Так при открытии документа из вкладки Генеральных договоров, на экран будет выведена базовая информация по выбранному полису (рис. 3.12). Рис. 3.12 Детальная информация Генерального договора Базовая информация Генерального договора подразумевает основную информацию по самому договору: номер полиса, дата его заключения, валюта договора, наименование страхователя и даты страхового периода. А также списки связанных с текущим договором объектов, таких как: Декларации, Бордеро, Финансовые документы, Заявки на проверку перевозчиков и Отчеты. Данные списки представлены на соответствующих вкладках и отображают базовую информацию об объектах, такую как: этап обработки, уникальный идентификатор и статус документа. 45

На каждой вкладке присутствует функционал для поиска нужного документа по уникальному идентификатору, а также добавления соответствующего нового объекта к договору. Для удобства использования системы и отслеживания своих действий и действий сотрудников авторизированного пользователя, реализован функционал логирования действий клиентов личного кабинета страховой компании результаты которого представлены в пункте меню «Логи» (рис. 3.13). При открытии данного пункта пользователю отображается таблица с данными о действиях, их дате выполнения и идентификатором клиента, выполнившего их. Также на вкладке присутствует поле для поиска логов действий определенного пользователя. Рис. 3.13 Отображение информации с вкладки «Логи» ЛК СК Также одним из дополнительных преимуществ разработанного личного кабинета, является наличие планировщика, представленного на вкладке «Календарь» (рис. 3.14). 46

Рис. 3.14 – Отображение планировщика с вкладки «Календарь» Разработанный планировщик имеет вид календаря, с возможностью выбора отображения расписания в трех вариантах: расписание на день, расписание на неделю и расписание на месяц. Данный модуль имеет функцию автоматической загрузки данных из реализованных автоматизированных бизнеспроцессов, а также возможность добавления и редактирования записей. 3.5 Тестирование разработанного функционала По окончанию разработки программного продукта было проведено ручное функциональное тестирование, которое показало, что продукт готов к выводу в продуктивное использование на этап поддержки и доработки. Как было описано в первой главе данной работы, с учетом используемой концепции на этапе аналитики бизнес-требований были написаны пошаговые пользовательские сценарии, описывающие разрабатываемый функционал. Данный подход представляет из себя парадигму BDD, что является разновидностью подхода TDD (Test Driven Development). Это обеспечивает специалиста, который должен проводить структурированной информацией по процессу. 47 тестирование, необходимой

Как правило, функциональные сценарии, которые обычно называют user cases, перерабатываясь в тестовые, практически неизменно дополняются пунктами с описанием ожидаемых состояний системы или её объектов после выполнения основных шагов. Функциональные сценарии, проанализированные и одобренные бизнесаналитиками со стороны компании-заказчика, позволяют быстро и однозначно точно реализовать проверку разработанного функционала. И выявить все несоответствия готового и ожидаемого продуктов. 48

ЗАКЛЮЧЕНИЕ В результате проведенной работы было установлено, что внедрение в процессы автоматизации концепции BPM и соответствующей системы разработки ПО, в частности Pega BPM, позволяет решить самые актуальные и сложные вопросы реализации современных программных продуктов, такие как: скорость разработки, нивелирование недопониманий между взаимодействующими специалистами разных профилей, участвующих в проекте, прозрачность процесса разработки на всех этапах, повышение качества итогового продукта, удобство дальнейших поддержки и доработок. На данный момент продукт ЛК СК запущен в тестовом режиме на серверах компаний разработчика и заказчика, и проходит этап бизнес-тестирования. За счет использования в процессе разработки подхода BDD, этап тестирования упрощается и сокращается, в силу предварительно написанных behaviorсценариев, являющихся полноценными тестовыми сценариями. Все автоматизированные процессы прозрачны для сотрудников, принимающих участие в разработке ЛК СК, так как принципы их работы были определены на ранних этапах и совместно специалистами как со стороны бизнесаналитики, так и со стороны команды разработки. В течение всего двух месяцев, продукт был проанализирован, разработан и прошел тестирование специалистами компании-разработчика и исследовательское тестирование специалистами со стороны заказчика. Этот показатель времени по завершению разработки удовлетворяет заказчика, что дает ему уверенность в самой концепции BPM, в подходе к работе с инструментом Pega 7.3 и мотивирует его на продолжение сотрудничества с компанией-разработчиком, выполнившей заказ. Платформа Pega 7.3, является инструментом для решения масштабных задач автоматизации процессов средней и большой категорий бизнеса. В силу достаточно высокой стоимости дополнительных профильных бизнес-надстроек, содержащих в себе вышеупомянутые шаблоны процессов, за счет использования 49

которых упрощается разработка продуктов для различных видов бизнесдеятельности, данный продукт не подходит для решения задач категории малого бизнеса. Все описанные в работе преимущества данной платформы нивелируют те незначительные недостатки, которые имеются у любой среды разработки ПО. Эти преимущества показывают, что продукт действительно является на сегодняшний день одним из немногих, отвечающих всем современным требованиям автоматизации внутренних процессов предприятий. 50

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 1. Суперека С.В. Страховое дело. 2008. [Электронный ресурс] URL: http://www.tamognia.ru/faq/detail.php?ID=1601180 2. Страхование грузов и грузоперевозок. 2017. [Электронный ресурс] URL: http://www.einsa.ru/strahovanie-gruzov.html 3. Сергей Сенюк. Gherkin: говорим с автоматизаторами на одном языке. 17 октября 2016. [Электронный ресурс] URL:http://www.a1qa.ru/blog/gherkingovorim-s-avtomatizatorami-na-odnom-yazyke 4. Е. О. Мартышкина. Процессный и функциональный подходы к управлению. 11 мая 2017. [Электронный ресурс] URL: http://studme.org/37057/ekonomika/protsessnyy_funktsionalnyy_podhody_upr avleniyu 5. Сергей Костяков. BPM-системы – инструмент консолидации. 27 марта 2018. [Электронный ресурс] URL:https://www.itweek.ru/idea/article/detail.php?ID=200134&param=rss 6. Николай Ешич. Знакомимся: Pega BPM. 8 сентября 2015. [Электронный ресурс] URL: http://ecm.ict-online.ru/news/n121551/ 7. Rob Dunie, W. Roy Schulte, Marc Kerremans, Michele Cantara. Magic Quadrant for Intelligent Business Process Management Suites. 18 august 2016. [Электронный ресурс]. URL: https://www.gartner.com/doc/reprints?id=13F580XF&ct=160818&st=sb 8. Селиверстова П.О., Точилкина Т.Е. Обзор лидеров BPMS // Экономика и менеджмент инновационных технологий. 2014. №12 [Электронный ресурс]. URL: http://ekonomika.snauka.ru/2014/12/6640 9. Appian BPM vs IBM Business Process Management. 29 august 2017. [Электронный ресурс]. URL: https://www.itqlick.com/Compare/appianbpm/ibm-business-process-management 10. Pegasystems Inc. System Architect Essentials – Student Guide 7.2 / Cambridge, MA, 2017 – 452 c. 11. Pegasystems Inc. System Architect Essentials – Exercise Guide 7.2 / Cambridge, MA, 2017 – 307 c. 12. Pegasystems Inc. Senior System Architect – Student Guide 7.2/ Cambridge, MA, 2017 – 450 c. 13. Pegasystems Inc. Senior System Architect – Exercise Guide 7.2/ Cambridge, MA, 2017 – 219 c. 14.Pegasystems Inc. Senior System Architect – Student Guide 7.1/ Cambridge, MA, 2015 – 551 c. 15.Pegasystems Inc. Lead System Architect – Student Guide 7.1/ Cambridge, MA, 2015 – 564 c. 51

16.Pegasystems Inc. Pega Customer Service Foundation – Student Guide 7.22/ Cambridge, MA, 2017 – 96 c. 17.Pegasystems Inc. Pega Customer Service Foundation – Exercise Guide 7.22/ Cambridge, MA, 2017 – 30 c. 18.Pegasystems Inc. System Administration Specialist – Student Guide 7.1/ Cambridge, MA, 2015 – 359 c 19. Neil Miller. Management System (BPMS) Must Have! 22 February 2018. [Электронный ресурс]. URL: https://kissflow.com/bpm/top-10-features-forbusiness-process-management-systems/ 20. Kamille Nixon. Top 5 Benefits of good Business Process Management. 19 December 2016. [Электронный ресурс]. URL: https://www.comindware.com/blog-benefits-of-business-process-management/ 21. Dr Alexander Samarin. Architecting enterprise BPM systems for optimal agility. [Электронный ресурс]. URL: http://www.improving-bpmsystems.com/pubs/AS-AW08-keynote.pdf 22. Joins & IBM BPM: Diving Deeper. 13 September 2013. [Электронный ресурс]. URL: https://www.comindware.com/blog-benefits-of-businessprocess-management/ 23. Pegasystems Inc. System Architect Essentials – Student Guide 7.3.1/ Cambridge, MA, 2018 – 315 c 24. Pegasystems Inc. System Architect Essentials – Exercise Guide 7.3.1/ Cambridge, MA, 2018 – 182 c 25.Pegasystems Inc. Business Architect Essentials – Student Guide 7.3.1/ Cambridge, MA, 2018 – 190 c 26. Pegasystems Inc. Business Architect Essentials – Exercise Guide 7.3.1/ Cambridge, MA, 2018 – 103 c 27.Pegasystems Inc. Certified Pega Decisioning Consultant – Student Guide 7.2.1/ Cambridge, MA, 2016 – 271 c 28. Pegasystems Inc. Certified Pega Decisioning Consultant – Exercise Guide 7.2.1/ Cambridge, MA, 2016 – 217 c 29. Pegasystems Inc. User Interface Specialist – Student Guide 7.2.1/ Cambridge, MA, 2015 – 487 c 30. Maarten Veger. The Top 3 things a Pega BPM consultant should be good at. 4 October 2017. [Электронный ресурс]. URL: http://bpmcompany.eu/blog/164the-top-3-things-a-pega-bpm-consultant-should-be-good-at 52

ПРИЛОЖЕНИЕ А Требования к реализуемому программному обеспечению: 1. Централизованное получение логина и пароля к ЛК, с возможностью дальнейшего подключения нескольких пользователей страхователя. Предусмотреть для пользователя ЛК возможность восстановления пароля по электронной почте. 2. Возможность поиска своих генеральных договоров (далее ГД), по номеру или выбор по списку, просмотра параметров (дата заключения, дата окончания, объект страхования, условия страхования, дополнительные риски) ГД, а также всех поданных деклараций (к конкретному ГД) со статусами. Условие: показывать только те ГД, которые привязаны к конкретному логину. 3. Возможность просмотра скана ГД. 4. Обеспечить интеграцию данных ГД из страховой системы в ЛК, автоматическое занесение необходимых параметров в поля декларации. Предусмотреть возможность ручного внесения дополнительной информации и прикрепления сканов документов. 5. Автоматическое формирование заявки на проверку и согласование по настроенным маршрутам. Настройка маршрутов согласования внутри страховой компании. 6. Разработка системных статусов ГД и его объектов. 7. Разработка печатных форм объектов ГД: декларация, извещение о страховом событии. 8. Предусмотреть сопровождение Страхователя путем online ответов на вопросы в чате внутри ЛК 9. Совместно с отделом проверки перевозчиков разработать и интегрировать в ЛК справочник благонадежных контрагентов (перевозчиков и водителей) и справочник «Стоп-лист» не (перевозчиков и водителей). 53 рекомендованных контрагентов

10. Предусмотреть автоматическое добавление в справочники новых контрагентов в зависимости от результатов их проверки. 11. Предусмотреть автоматическую проверку достаточности данных для расчета страховой премии в ЛК. Разработать калькулятор для автоматического расчета страховой премии. 12. Предусмотреть процедуру автоматического формирование клиентского счета по итогам расчетного периода. 13. Формирование ролевой модели с разделением прав доступа в соответствии с необходимым бизнес-процессом. 54

Рецензии:

Авторизуйтесь, чтобы добавить рецензию

- у работы пока нет рецензий -

Отзывы:

Авторизуйтесь, чтобы оставить отзыв