Моделирование бизнес процессов дипломная работа

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

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

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

Группа предприятий «Цербер» существует на рынке Перми и Пермского края более 20 лет. Сферой деятельности данного предприятия является оказание услуг по физической, технической и пожарной охране объектов. Одной из проблем предприятия является затраты большого количества времени для исполнения бизнес-процессов, происходящих внутри коммерческого отдела. К таким бизнес-процессам можно отнести работу с клиентами, составление рутинных, однотипных документов и их дальнейшее согласование с начальником отдела и т.д.

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

Главной проблемой группы предприятий «Цербер» является отсутствие описание бизнес-процессов. В данный момент существуют лишь текстовые описания в виде регламентов.

Для достижения поставленной цели были поставлены следующие задачи:

.        Изучение внутренних регламентов и уставов группы предприятий «Цербер».

.        Построение моделей бизнес-процессов в выбранной нотации.

.        Построение прототипа системы, автоматизирующей управление бизнес-процессами.

Объектом исследования являются бизнес-процессы группы предприятий «Цербер». Предметом исследования являются средства анализа и моделирования бизнес-процессов коммерческого отдела группы предприятий «Цербер».

Глава 1. Анализ предметной области

Для построения модели бизнес-процессов коммерческого отдела группы предприятий «Цербер» необходимо выбрать нотацию, обладающую такими критериями, как отображение временной последовательности работ, низкой сложностью изучения языка, возможностью описать работу на «нижнем уровне». После выбора нотации, в которой будут строиться модели, необходимо выбрать программный продукт. Выбранное средство моделирования должно быть в бесплатном доступе, полностью соответствовать всем правилам построения моделей в выбранной нотации, а также иметь возможность моделирования работы бизнес-процессов.

.1 Анализ существующих нотаций

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

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

·        Отображение временной последовательности работ. Данный критерий важен, т.к. описание бизнес-процессов будет происходить на «нижнем уровне», в котором важно знать последовательность выполнение этапов работы бизнес-процесса.

·        Отсутствие ограничения количества блоков.

·        Наглядность диаграмм. Построенные модели бизнес-процессов должны быть понятны для любого пользователя.

Ниже будут рассмотрены и проанализированы наиболее часто используемые методики описания бизнес-процессов.

.1.1 IDEF0

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

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

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

На рисунке 1.1 изображен бизнес-процесс выполнения платежей в IDEF0 нотации. В данном примере можно увидеть, что на вход в первый блок «Составить заявку на платеж» сначала инициатором платежа подается бланк заявки на платеж, который оформляется, основываясь на регламенте подтверждения платежей и бюджете проекта. Затем данная заявка согласовывается с инициатором проекта и спонсором проекта и после ее утверждения проверяется финансовым менеджером с помощью счетов на оплату. После того, как финансовый менеджер утвердил заявку бухгалтер проекта формирует первичные документы по платежу и затем с помощью денежных средств оплачивает данный проект.

Рисунок 1.1 Пример IDEF0 нотации

В результате рассмотрения данной нотации можно сделать вывод, что она не подходит для выполнения поставленной цели.

.1.2 IDEF3

IDEF3 — это нотация, которая используется для описания и построения процессов нижнего уровня, например, для описания процессов работ на рабочих местах или выполняемых внутри подразделений. Также данная нотация может быть использована для декомпозиции блоков процесса IDEF0. Основной целью нотации IDEF3 является описание потоков работ (Work Flow Modeling) [2].

Основными графическими объектами модели, используемыми в IDEF3, являются прямоугольники и стрелки. Первые служат для описания функций (работ, процессов), вторые — для отражения в модели последовательности выполнения функций во времени либо последовательности выполнения функций.

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

1.  Логический оператор «И».

2.       Логический оператор «ИЛИ».

.        Логический оператор — исключающее «ИЛИ».

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

При декомпозиции процессов в IDEF3 не происходит мигрирования и туннелирования стрелок. Аналитик должен сам заботиться о связности моделирования процесса и корректности декомпозиции.

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

На рисунке 1.2 показан пример IDEF3 нотации, в котором изображен процесс совершения сделки между клиентом и агентством недвижимости. В данном процессе описана последовательность действий работников агентства недвижимости начиная от получения информации от клиента до завершения сделки после бронирования квартиры или составления договора.

Рисунок 1.2. Пример IDEF3 нотации

В результате рассмотрения данной нотации можно сделать вывод, что она не удовлетворяет критериям для выполнения цели выпускной квалификационной работы.

.1.3 UML

UML-диаграмма — это язык графического описания, который предназначен для моделирования объектов в сфере разработки различного программного обеспечения. Данный язык представляет собой некий открытый стандарт, при помощи которого создаются разнообразные модели системы, используя различные графические обозначения [3].

Используя язык UML разработчики программного обеспечения могут прийти к общим обозначениям различных понятий. Это помогает в дальнейшем достичь в большей степени концентрации на проектировании и архитектуре диаграмм.

Также стоит отметить, что на данный момент существует 12 различных типов диаграмм:

.        Диаграмма классов.

.        Диаграмма компонентов.

.        Диаграмма композитной/составной структуры.

.        Диаграмма развертывания.

.        Диаграмма пакетов.

.        Диаграмма деятельности.

.        Диаграмма объектов.

.        Диаграмма автомата.

.        Диаграмма сценариев использования.

.        Диаграмма синхронизации.

.        Диаграмма обзора взаимодействия.

.        Диаграммы коммуникации и последовательности.

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

Рисунок 1.3. Пример диаграммы деятельности

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

Рисунок 1.4. Пример диаграммы сценариев использования

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

Рисунок 1.5. Пример диаграммы последовательности

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

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

1.1.4 EPC

Нотация EPC (Event-Driven Process Chain) — это нотация, которая используется для описания бизнес-процессов в виде последовательности событий и функций. В основном используется для описания бизнес-процессов на нижнем уровне [4].

Основным принципом нотации, на котором все строится, является понятие событийности. Главными элементами для построения основной части диаграммы являются события и функции. Далее после построения основного каркаса диаграммы происходит наполнение диаграммы различными элементами, например, «База данных», «Участник процесса» и т.д.

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

.        Логическое «И» (AND).

.        Логическое «ИЛИ» (OR).

.        Исключающее «ИЛИ» (XOR).

Пример на рисунке 1.6 описывает бизнес-процесс оформления депозита с помощью EPC-нотации. На данном рисунке мы можем увидеть, что все функции и события заключены в зеленые прямоугольники и оранжевые шестиугольники соответственно. Актеры, которые выполняют отведенные им события указываются на диаграмме желтыми прямоугольниками. Документы, использующиеся в процессе оформления депозита указаны в серых прямоугольниках.

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

Рисунок 1.6. Пример EPC-нотации

.1.5 BPMN

BPMN (Business Process Model and Notation) — это система условных обозначений для моделирования бизнес-процессов. Данная спецификация описывает условные обозначения для отображения бизнес-процессов. Достаточно проста как для бизнес-пользователей, так и для технических специалистов [5].

Основной целью BPMN является создание стандартного набора условных знаков понятных всем пользователям данной нотации. По уверениям создателей данной нотации, в нее вошли все достоинства от таких нотаций как: EPC, UML, ADF Diagram.

На рисунке 1.7 представлен бизнес-процесс формирования и согласования документа на закупку товара в BPMN нотации. Данный бизнес-процесс достаточно легок и понятен для чтения и дальнейшего его понимания в связи с тем, что на схеме легко понять какие процессы выполняются актером «Заказчик», а какие актером «Госкомзаказ».

Рисунок 1.7. Пример BPMN нотации

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

К недостаткам BPMN нотации можно отнести достаточно скудные возможности в описании информационной архитектуры предприятия.

В таблице 1.1 представлен сравнительный анализ рассмотренных выше нотаций по выбранным критериям. В результате изучения нотаций, анализа их достоинств и недостатков с учетом поставленных критериев было принято решение об использовании BPMN нотации для решения поставленной в исследовании задачи.

Таблица 1.1. Сравнительная таблица нотаций

.2 Анализ программных продуктов

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

Основными критериями для выбора средства моделирования выделены следующие параметры:

·        Полное соответствие стандарту BPMN 2.0.

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

·        Наличие проверки на ошибки. Во время построения моделей разработчик может допустить ошибки, которые в дальнейшем приведут к тому, что модель будет являться не эффективной.

·        Наличие бесплатной версии программы.

В рамках исследования существующих программных продуктов будут рассмотрены достоинства и недостатки каждой программы.

.2.1 Microsoft Visio

Решение от Microsoft является наиболее доступным из платных версий программ. Создание схем в BPMN нотации возможно в любой из версий программы, однако проверка схемы на корректность и наличие шаблонов возможна только в версиях Microsoft Visio 2010 Premium, Microsoft Visio 2013 Professional и Microsoft Visio 2016 Professional. Так же к недостаткам стоит отнести то, что некоторые элементы нотации отсутствуют.

К достоинствам программы стоит отнести удобство пользования данной программой, как и многими офисными решениями от компании Microsoft. Еще одним достоинством программного продукта является его синхронизация с другими программными продуктами Microsoft и возможность вставлять схемы в документы в качестве встроенных объектов, которые можно изменять, не используя Microsoft Visio.

На рисунке 1.8 представлен пример рабочего окна Microsoft Visio 2016, в котором создан пример изменения адреса.

В данный момент приобрести можно только Microsoft Visio 2016 Professional. Цена за электронную версию данной программы составляет 27 000 руб.

Рисунок 1.8. Пример рабочего окна Microsoft Visio

.2.2 BPM 2.0 modeler for Visio

Данное решение является не программным продуктом, а всего лишь надстройкой к Microsoft Visio, которое добавляет в необходимый функционал для полноценной работы с BPMN нотацией в программном продукте от компании Microsoft.

Благодаря данному решению в Visio появились новые возможности, например, выгрузка результатов в таких форматах, как XPDL и BPEL. Благодаря данному решению, появилась возможность создавать модели, полностью соответствующие BPMN 2.0 стандартам.

У данного решения существует как платная, так и пробная версия на 30 дней.

.2.3 Bizagi Process Modeler

Bizagi Process Modeler — это решение, созданное компанией Bizagi для моделирования бизнес-процессов в BPMN нотации. Данная программа является одной из самых популярных ввиду своей функциональности, простоты и бесплатности.

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

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

На рисунке 1.9 представлен пример схемы, созданной в Bizagi Process Modeler.

Рисунок 1.9. Пример схемы в Bizagi Process Modeler

.2.4 ARIS Express

ARIS Express — это бесплатная версия программы ARIS, предназначенная для моделирования бизнес-процессов и организационно структуры предприятий. Данный продукт широко представлен на российском рынке.

ARIS Express поддерживает следующие типы моделей:

1.   Организационная диаграмма (Organizational chart).

2.         Бизнес-процесс (Business process).

3.         ИТ-инфраструктура (IT infrastructure).

4.         Карта процессов (Process landscape).

5.         Модель данных (Data model).

6.         Карта систем (System landscape).

7.         Доска (Whiteboard).

8.         BPMN диаграмма версии 2.0 (BPMN diagram).

9.         Общие диаграммы (General diagram).

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

К недостаткам ARIS Express в сравнении с платной версией программы можно отнести отсутствие поддержки связи между создаваемыми объектами, то есть при внесении изменений в одну модель программа не будет вносить изменения в другую модель. Еще одним недостатком программы является отсутствие инструментов для формирования отчетов и средств анализа модели.

В сравнении с конкурентами на рынке ARIS Express не обладает возможностью выгрузки моделей в форматы XPDL и BPEL. Также данная программа обладает некоторыми ограничениями в количестве элементов, которые могут быть добавлены на схему, что также осложняет работу в программе с большими схемами.

На рисунке 1.10 представлен пример рабочего окна ARIS Express.

Рисунок 1.10. Пример работы в ARIS Express

В таблице 1.2 представлена итоговая таблица сравнения программных продуктов.

Таблица 1.2. Сравнительная таблица программных продуктов

В результате анализа программных продуктов, наиболее подходящим для решения поставленных задач и удовлетворяющим всем критериям, является программа Bizagi Process Modeler.

Глава 2. Проектирование бизнес-процессов

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

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

.        Изучить устав и регламенты, регулирующие деятельность коммерческого отдела.

.        Выяснить, какие документы используются во время выполнения бизнес-процесса.

.        Определить актеров каждого из бизнес-процессов.

.        Выяснить, кто является владельцем бизнес-процесса

.        Выяснить, какие шаги выполняются каждым актером.

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

.        Определить последовательность всех шагов бизнес-процесса.

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

.        Выяснить возможное время выполнения бизнес-процесса при разных возможных условиях.

.        Определить денежные затраты, которые уходят на выполнение бизнес-процесса.

После выполнения анализа бизнес-процесса будет построена модель бизнес-процесса в BPMN 2.0 нотации, выполненная в программе Bizagi Modeler. После этапа построения модели будут разработаны различные сценарии выполнения бизнес-процесса, а затем выполнен анализ бизнес-процессов с помощью имитационного моделирования для выявления наиболее затратных шагов в бизнес-процессе.

На рисунке 2.1 показана схема организационной структуры группы предприятий «Цербер».

Рисунок 2.1. Организационная структура предприятия

На рисунке 2.2 показана структура коммерческого отдела группы предприятий «Цербер».

Рисунок 2.2. Структура коммерческого отдела

2.1 Анализ бизнес-процесса «Прием объекта на охрану»

Документ, регулирующий выполнение бизнес-процесса: Инструкция по организации охраны предприятия (объединения) [6].

Владелец бизнес-процесса: активный менеджер коммерческого отдела группы предприятий «Цербер».

В данном бизнес-процессе задействованы следующие исполнители:

.        Клиент.

.        Активный менеджер.

.        Инженер технического отдела.

.        Начальник коммерческого отдела.

.        Коммерческий директор.

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

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

Пошаговое описание бизнес-процесса:

.        Клиент оставляет заявку о желании поставить объект на охрану.

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

.        Активный менеджер предоставляет информацию клиенту о пакете необходимых документов для дальнейшей работы.

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

.        Активный менеджер составляет заявку на осмотр объекта инженером технического отдела.

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

.        После осмотра объекта инженером составляется отчет об осмотре объекта, в котором отображается схема объекта, необходимое оборудование и расшифровка условных знаков и обозначений.

.        Инженер предоставляет отчет об осмотренном объекте активному менеджеру.

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

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

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

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

.        После согласования договора с начальником коммерческого отдела, документ согласуется с коммерческим директором. Если у коммерческого директора есть замечания, то они исправляются менеджером и заново передаются на согласование. В случае, если замечаний нет, то далее документ передается на подпись.

.        Договор подписывается обеими сторонами.

.        Согласовывается дата установки оборудования, которая наиболее удобна клиенту.

.        Менеджер составляет заявку на установку оборудования на объекте. В случае, если установка не возможна в указанное клиентом время, менеджер заново согласует дату установки оборудования.

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

Возможные бизнес-условия:

.        Стоимость, указанная менеджером, удовлетворяет клиента.

.        Стоимость, указанная менеджером, не удовлетворяет клиента.

.        Стоимость, с учетом предоставленной скидки удовлетворяет клиента.

.        Стоимость, с учетом предоставленной скидки не удовлетворяет клиента.

Возможные варианты завершения бизнес-процесса:

.        Клиент отказывается от предоставляемых услуг в виду их большой цены.

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

.        Клиенту устанавливается оборудование согласно договору на оказание охранных услуг.

Документы, использующиеся в бизнес-процессе:

.        Заявка на предоставление охранных услуг.

.        Заявка на осмотр объекта.

.        Отчет об осмотре объекта.

.        Договор на оказание охранных услуг.

.        Заявка на установку оборудования на объекте.

Матрица связности операций бизнес-процесса и элементов организационной структуры предприятия представлена ниже в таблице 2.1 и таблице 2.2.

Таблица 2.1. Матрица связанности операций и элементов организационной структуры предприятия

Таблица 2.2. Матрица связанности операций и элементов организационной структуры коммерческого отдела

В таблице 2.3 представлена информация об исполнителях и их заработной плате за месяц, а указана также почасовая оплата.

Таблица 2.3. Таблица зарплат исполнителей

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

Таблица 2.4. Временные и денежные затраты операций

В таблице 2.5 представлена матрица связности операций и бизнес-событий.

Таблица 2.5 Матрица связности операций и бизнес-событий

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

Таблица 2.6 Матрица связности бизнес-событий и бизнес-условий

В таблице 2.7 представлена матрица связности документов и операций бизнес-процесса.

Таблица 2.7 Матрица связности документов и операций бизнес-процесса

В результате проведенного анализа была построена модель бизнес-процесса (см. Приложение А). После построения модели необходимо провести симуляцию. Для этого Bizagi Modeler имеет специальный инструмент. Было разработано три разных сценария, которые различаются между собой временем ожидания начала следующего шага бизнес-процесса, количеством экземпляров процесса, условиями выполнения шагов на шлюзах построенной модели. Согласно предоставленной информации, в среднем в месяц один активный менеджер работает с 8-10 новыми клиентами.

Для симуляции работы модели были разработаны следующие три сценария.

Условия для первого сценария:

.        Количество подаваемых заявок — 8, заявки приходят с интервалом в полтора часа.

.        Стоимость предоставляемых услуг удовлетворяет 80% клиентов.

.        В случае неудовлетворенности стоимостью услуг, клиент в 80% случаев просит о снижении стоимости и в 20% случаев отказывается от предоставления ему услуг.

.        В 90% случаев клиент соглашается на стоимость услуг после предоставления ему скидки или поиска альтернативного оборудования.

.        В 75% случаев возможна установка оборудования в указанное клиентом время.

.        Время ожидания перед осмотром объекта 45 минут, на остальных шагах -0.

.        При согласовании замечаний нет.

Условия для симуляции второго сценария:

.        Количество подаваемых заявок — 8, заявки приходят с интервалом в 12 часов.

.        Стоимость предоставляемых услуг удовлетворяет 80% клиентов.

.        В случае неудовлетворенности стоимостью услуг, клиент в 80% случаев просит о снижении стоимости и в 20% случаев отказывается от предоставления ему услуг.

.        В 90% случаев клиент соглашается на стоимость услуг после предоставления ему скидки или поиска альтернативного оборудования.

.        В 75% случаев возможна установка оборудования в указанное клиентом время.

.        Время ожидания перед приемом заявки — 5 минут.

.        Время ожидания перед осмотром объекта — 1 день.

.        Время ожидания перед согласованием — 30 минут.

.        В 75% случаев замечаний нет.

.        Время ожидания перед установкой оборудования — 1 день.

Условия для симуляции третьего сценария:

.        Количество подаваемых заявок — 10, заявки приходят с интервалом в 4 часа.

.        Стоимость предоставляемых услуг удовлетворяет 70% клиентов.

.        В случае неудовлетворенности стоимостью услуг, клиент в 90% случаев просит о снижении стоимости и в 10% случаев отказывается от предоставления ему услуг.

.        В 80% случаев клиент соглашается на стоимость услуг после предоставления ему скидки или поиска альтернативного оборудования.

.        В 40% случаев возможна установка оборудования в указанное клиентом время.

.        Время ожидания перед приемом заявки — 10 минут.

.        Время ожидания перед осмотром объекта — 2 дня.

.        Время ожидания перед составлением документации об объекте — 2 часа.

.        Время ожидания перед согласованием — 1 час.

.        В 50% случаев замечаний нет.

.        Время ожидания перед установкой оборудования — 3 дня.

.        Время ожидания перед расчетом стоимости установки оборудования — 1 час.

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

Таблица 2.8. Сценарий 1

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

Таблица 2.9. Сценарий 2

проектирование автоматизация управление бизнес

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

Таблица 2.10. Сценарий 3

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

В таблице 2.11 отражены денежные затраты исполнителей при различных сценариях.

Таблица 2.11. Денежные затраты на исполнителей

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

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

.2 Анализ бизнес-процесса «Создание рекламной продукции»

Документ, регулирующий выполнение бизнес-процесса: Положение о финансировании рекламной деятельности на предприятии [11].

Владелец бизнес-процесса: маркетолог.

В данном бизнес-процессе задействованы следующие исполнители:

.        Маркетолог.

.        Генеральный директор.

.        Совет директоров.

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

В случае, если готовый рекламный продукт утверждается генеральным директором, то он выпускается в СМИ, в противном случае от рекламного продукта отказываются.

Пошаговое описание бизнес-процесса:

.        Маркетолог начинает разрабатывать план выпуска рекламной продукции на следующий год.

.        Маркетолог анализирует имеющуюся у него информацию об эффективности различных видов рекламы. Эти данные он получает после опросов клиентов о том, как клиенты узнали о компании.

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

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

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

.        Маркетолог составляет план выхода рекламной продукции в СМИ на следующий год.

.        Маркетолог производит расчет затрат на создание рекламной продукции и дальнейший ее выпуск в СМИ.

.        Маркетологом составляется отчет, включающий в себя весь анализ и передается на согласование совету директоров.

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

.        Генеральный директор утверждает годовой план при отсутствии замечаний. При наличии замечаний, годовой план передается маркетологу для внесения изменений и дальнейшего согласования с генеральным директором.

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

.        На основе существующих рекламных продуктов и потребительских желаний создается новый рекламный продукт.

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

.        Совет директоров при наличии замечаний передает рекламный продукт маркетологу для изменения. При отсутствии замечаний рекламный продукт передается на согласование генеральному директору.

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

.        Маркетолог передает готовый рекламный продукт в СМИ.

Возможные бизнес-условия:

.        Генеральный директор указал на замечания в рекламном продукте

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

Возможные варианты окончания данного бизнес-процесса:

.        Выпуск рекламного продукта в СМИ.

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

Документы, участвующие в бизнес-процессе:

.        Годовой план расходов на рекламную продукцию.

.        Существующая рекламная продукция.

.        Готовая рекламная продукция.

В таблице 2.12 показана матрица связанности операций и элементов организационной структуры.

Таблица 2.12. Матрица связанности операций и элементов организационной структуры

В таблице 2.13 представлена информация об исполнителях и их заработной плате за месяц, а указана также почасовая оплата.

Таблица 2.13. Таблица зарплат исполнителей

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

Таблица 2.14. Временные и денежные затраты операций

Связь между бизнес-событиям и операциями представлена в табл. 2.15.

Таблица 2.15. Матрица связности операций и бизнес-событий

Матрица связности между бизнес-событиями и бизнес-условиями представлена в табл. 2.16.

Таблица 2.16 Матрица связности бизнес-событий и бизнес-условий

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

Таблица 2.17 Матрица связности документов и операций бизнес-процесса

В результате проведенного анализа была построена модель бизнес-процесса (см. Приложение В). После построения модели была проведена симуляция. Для анализа работы бизнес-процесса было создано три сценария.

Условия для первого сценария:

.        Количество заявок — 7, интервал появления заявок — 60 минут.

.        Время ожидания у всех шагов процесса — 0 минут.

.        Годовой план и готовый рекламный продукт согласуется сразу, замечаний ни у кого из исполнителей нет.

.        Количество людей в совете директоров — 5.

Условия для второго сценария следующие:

.        Количество заявок — 9, интервал появления заявок — 200 минут.

.        Время ожидания для анализа ценностей для потребительских групп — 1 час.

.        Время ожидания для анализа эффективности работы СМИ — 30 минут.

.        Время ожидания для согласования годового плана — 2 часа.

.        Время ожидания для согласования готового рекламного продукта — 2 часа.

.        В 75% случаев замечаний во время согласования как годового плана, так и готового рекламного продукта нет.

Для третьего сценария были выбраны следующие условия:

.        Количество заявок — 10, интервал появления заявок — 100 минут.

.        Время ожидания для анализа ценностей для потребительских групп — 30 минут.

.        Время ожидания для анализа эффективности работы СМИ — 1 час.

.        Время ожидания для согласования годового плана — 1 час.

.        Время ожидания для согласования готового рекламного продукта — 1 час.

.        В 75% случаев замечаний во время согласования у совета директоров как годового плана, так и готового рекламного продукта нет.

.        В 50% случаев замечаний во время согласования у генерального директора как годового плана, так и готового рекламного продукта нет.

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

Таблица 2.18. Сравнение сценариев

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

В таблице 2.19 указана информация о денежных затратах на выполнение данного бизнес-процесса исполнителями.

Таблица 2.19. Денежные затраты на исполнителей

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

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

.3 Анализ бизнес-процесса «Снятие объекта с охраны»

Документ, регулирующий выполнение бизнес-процесса: Положение о расторжении договора с клиентом и снятии объекта с охраны [12].

Владелец бизнес-процесса: активный менеджер.

В данном бизнес-процессе задействованы следующие исполнители:

.        Клиент.

.        Активный менеджер.

.        Начальник коммерческого отдела.

.        Коммерческий директор.

.        Инженер технического отдела.

Входом бизнес-процесса является заявка клиента о снятии объекта с охраны.

В результате выполнения бизнес-процесса на объекте демонтируется все поставленное ранее оборудование и расторгается договор между клиентом и группой предприятий «Цербер»

Пошаговое описание бизнес-процесса:

.        Клиент подает заявку на снятие объекта с охраны.

.        Активный менеджер принимает заявку.

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

.        Активный менеджер передает акт на согласование.

.        Начальник коммерческого отдела согласует документ и подписывает его.

.        Активным менеджером составляет заявка на демонтаж оборудования на объекте.

.        Инженер технического отдела принимает заявку.

.        Инженер технического отдела производит демонтаж оборудования на объекте клиента.

.        Инженер составляет отчет о выполненной работе.

.        Клиент подписывает акт о снятии объекта с охраны.

Возможные варианты окончания данного бизнес-процесса:

.        Снятие объекта с охраны.

Документы, участвующие в бизнес-процессе:

. Акт о снятии объекта с охраны.

. Заявка на демонтаж оборудования на объекте.

. Отчет о выполнении работ.

Таблица 2.20. Матрица связанности операций и элементов организационной структуры предприятия

В таблице 2.21 представлена информация об исполнителях и их заработной плате за месяц, а указана также почасовая оплата.

Таблица 2.21. Таблица зарплат исполнителей

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

Таблица 2.22. Временные и денежные затраты операций

В таблице 2.23 представлена матрица связности документов и операций бизнес-процесса.

Таблица 2.23. Матрица связности документов и операций бизнес-процесса

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

Для симуляции работы модели были разработаны следующие два сценария.

Условия для симуляции первого сценария:

.        Количество подаваемых заявок — 7.

.        Заявки приходят с интервалом в 30 минут.

.        Время ожидания перед каждым шагом — 0 минут.

.        При согласовании замечаний нет.

Условия для симуляции второго сценария:

.        Количество подаваемых заявок — 7.

.        Заявки приходят с интервалом в 120 минут.

.        Время ожидания перед шагами от 1 минуты до 1 часа.

.        При согласовании и подписи акта замечаний для исправления нет.

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

Таблица 2.24. Сравнение сценариев

В таблице 2.25 указана информация о денежных затратах на выполнение данного бизнес-процесса исполнителями.

Таблица 2.25. Денежные затраты на исполнителей

В результате построения модели и симуляции возможных вариантов работы были получены затраты на выполнение данного бизнес-процесса. Из полученных результатов выполнения симуляции можно сделать вывод, что в бизнес-процессе «Снятие объекта с охраны» основные денежные и временные затраты приходятся на активного менеджера и инженера технического отдела.

Глава 3. Построение системы управления бизнес-процессами   .1 Выбор BPM-системы для автоматизации бизнес-процессов

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

Основными критериями для выбора системы выделены следующие параметры:

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

. Наглядность схем. Созданные в программе схемы должны быть наглядными и понятными для всех пользователей.

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

. Наличие бесплатной версии программы.

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

Концепция предполагает внедрение BPM-решения для достижения следующих целей:

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

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

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

·              Гибкость. Участники бизнес-процесса имеют возможность принять участие в моделировании бизнес-процесса и внесении в него каких-либо изменений [10].

В настоящее время большое количество компаний внедряют различные BPM-cсистемы для оптимизации своих бизнес-процессов. Ввиду большого спроса на BPM-системы, на рынке появилось множество различных программных продуктов, с помощью которых можно решить поставленные задачи, а при необходимости даже изменить стандартную систему специально для своей компании. Сравнительный анализ был осуществлен по четырем различным системам, имеющим наибольшую известность и распространенность на российском рынке. Это системы «RunaWFE», «ELMA BPM», «Bonita BPM», «Bizagi BPM Suite».

Первой системой, которая будет рассмотрена в данном сравнении — это российская программа «RunaWFE». В данную разработку включены следующие компоненты:

·    RunaWFE- сервер.

·        Web-интерфейс.

·        Клиент-оповещатель о поступивших заданиях.

·        Внутренний графический дизайнер бизнес-процессов.

·        Симулятор бизнес-процессов.

На рисунке 3.1 представлена подробная модель компонентов RunaWFE.

Рисунок 3.1. Модель компонентов RunaWFE

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

Графический редактор RunaWFE поддерживает нотацию BPMN, имеет симуляцию бизнес-процессов и встроенную проверку моделей на корректность и соответствие правилам создания моделей в данной нотации.является открытой программой, которую каждая компания может настроить специально под свои нужды. Для построения системы требуются знания BPMN нотации, а при создании больших и сложных моделей также могут потребоваться знания языка JAVA для написания скриптов и языка HTML для настройки форм.

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

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

Следующей рассматриваемой системой стала также российское решение «ELMA BPM». На рисунке 3.2 представлена архитектура системы ELMA [7].

Рисунок 3.2. Архитектура системы ELMA

Создание системы в данном программном продукте начинается с построение модели в специальном графическом редакторе «Дизайнер ELMA» в нотации BPMN 2.0. Затем разработчик выбирает различные параметры выполнения процесса и определяет данные, с которыми будет работать бизнес-процесс. После этого готовая схема публикуется на сервер системы и дальнейшее создание системы происходит в веб-интерфейсе.

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

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

К недостаткам ELMA BPM можно отнести ее стоимость — 10 тысяч рублей за 1 рабочее место, а бесплатная версия рассчитана только на 5 рабочих мест. Также основным минусом данного программного решения является поддержка упрощенной версии BPMN, что может помешать разработке системы, в которой будут использоваться редкие элементы.

Следующей системой для сравнения стала Bonita Open Solution. Ее архитектура представлена на рисунке 3.3.

Рисунок 3.3. Архитектура Bonita Open Solution

Решение французских разработчиков состоит из трех основных компонентов:

·        Studio. В данном компоненте происходит моделирование и дальнейшая автоматизация бизнес-процессов.

·        Execution Engine. Компонент предназначен для исполнения бизнес-процессов.

·        User Experience. Web- интерфейс, в котором настраивается вся последующая работа системы.

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

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

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

Последняя рассматриваемая система — Bizagi BPM Suite. На рисунке 3.4 представлена архитектура данной системы.

Рисунок 3.4. Архитектура Bizagi BPM Suite

BPM Suite состоит из трех компонентов, каждый из которых выполняет отдельные функции:

·        Bizagi Process Modeler — дизайнер процессов. В данном компоненте создаются модели в нотации BPMN 2.0. Поддерживается полный уровень соответствия правилам создания моделей в данной нотации. Дизайнер процессов является наиболее сильной стороной от компании Bizagi, благодаря которому компания и стала знаменита, а ее продукты популярны.

·        Bizagi Studio — автоматизация процессов. Данный модуль используется на предприятиях для определения всей необходимой информации для автоматизации процессов.

·        Bizagi BPM Server — исполнение процесса. Модуль, используемый для работы процесса.

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

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

На таблице 3.1 представлена итоговая таблица сравнения BPM-систем.

Таблица 3.1. Сравнительная таблица BPM-систем

В результате изучения существующих BPM-систем было принято решение использовать программный продукт RunaWFE. Главными факторами, которые повлияли на выбор данной системы стали ее бесплатность и наличие русифицированной документации, находящейся в свободном доступе. Поддержка только упрощенной версии нотации BPMN не будет являться проблемой, так как в моделях не присутствуют элементы, которые не поддерживает графический редактор RunaWFE.

3.2     Построение прототипа автоматизированного процесса «Прием объекта на охрану»

Построение прототипа автоматизированного процесса начинается с построения модели процесса в редакторе Runa WFE. Построенная в Runa WFE модель немного была упрощена в сравнении с моделью, построенной в Bizagi Process Modeler, в связи с особенностями используемой программы, при этом понимание модели осталось на прежнем уровне. Так, например, часть процесса, описывающая процесс согласования документа с начальником коммерческого отдела и коммерческим директором, которая выглядит в Bizagi Process Modeler так, как изображено на рисунке 3.5, в RunaWFE Process Designer выглядит так, как на рисунке 3.6. Благодаря тому, что в RunaWFE Process Designer есть возможность не разделять элементы бизнес-процесса отдельно для каждой роли, как это осуществляется в Bizagi Process Modeler, модель выглядит меньше по своему размеру и остается легкой для понимания любыми пользователями.

Рисунок 3.5. Согласование документов в Bizagi Modeler

Рисунок 3.6. Согласование документов в RunaWFE

После создания модели в графическом редакторе необходимо создать роли, которые будут выполнять отдельные этапы бизнес-процесса. Роли в RunaWFE создаются в двух компонентах — Process Designer и Simulation web interface. На рисунке 3.7 представлена вкладка создания ролей.

Рисунок 3.7. Вкладка «Роли»

Для процесса «Постановка объекта на охрану» были выявлены следующие роли:

·        Клиент.

·        Активный менеджер.

·        Инженер технического отдела.

·        Начальник коммерческого отдела.

·        Коммерческий директор.

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

Рисунок 3.8. Вкладка «Пользователи»

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

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

На следующем этапе работы необходимо определить все переменные, которые необходимы для выполнения процесса. К переменным относятся строки для ручного заполнения, файлы, которые необходимы для работы данного процесса, переменные типа «Дата» и «Флаг (логическое выражение)».

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

После выполнения всех необходимых работ и настройки системы для ее корректной работы необходимо проверить ее на наличие ошибок. Для этого зайдем в систему под пользователем Баранов, запустим процесс «Постановка объекта на охрану» и заполним форму.

Затем после приема заявки активный менеджер Пименова загружает в систему копию паспорта клиента и необходимый пакет документов на объект.

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

После подачи заявки менеджером, инженер технического отдела должен осмотреть объект и составить его схему.

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

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

1.   Начальник коммерческого отдела.

2.       Коммерческий директор.

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

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

После этого инженером технического отдела устанавливается оборудование на объекте и отчитывается об этом в системе.

3.3 Построение автоматизированного процесса «Создание рекламы»

В результате анализа во второй главе, в данном процессе были выделены следующие роли:

.        Маркетолог.

.        Совет директоров.

.        Генеральный директор.

Процесс создания и настройки системы идентичен процессу, описанному выше в п. 3.1, поэтому подробное описание здесь будет опущено.

Затем маркетологом составляется годовой план выхода рекламы в СМИ. В данном плане указываются какие именно виды рекламы будут выходить в СМИ в зависимости от времени года. Форма выполнения данного задания представлена на рисунке 3.28.

Рисунок 3.28. Форма «Составление плана выхода рекламы в СМИ»

После того, как составлен план, маркетолог приступает к расчету затрат на создание рекламы. Форма выполнения задания представлена на рисунке 3.29.

Рисунок 3.29. Форма «Составление отчета о затратах на рекламу»

На основании созданных ранее отчетов создается годовой план расходов в который входят представленные выше отчеты. Форма выполнения данного этапа бизнес-процесса представлена на рисунке 3.30.

Рисунок 3.30. Форма «Составление годового плана расходов на рекламу»

После создания годового плана он передается на согласование. Форма для передачи документа на согласование показана на рисунке 3.31.

Рисунок 3.31. Форма «Передача на согласование»

После того как документ передан на согласование, то его рассматривают сначала совет директоров, а в дальнейшем документ представляется для согласования генеральному директору. Форма согласования для совета директоров и генерального директора абсолютно идентична и представлена на рисунке 3.32. Если документ не согласован, то он передается маркетологу для внесения в него изменений.

Рисунок 3.32. Форма «Согласование документа»

После того, как годовой план согласован маркетолог приступает к выполнению данного плана и созданию рекламной продукции. После того, как рекламный продукт создан, он загружается в систему (см. рисунок 3.33) и передается на согласование совету директоров и генеральному директору. Согласование готового рекламного продукта проходит идентично согласованию годового плана. В случае, если рекламный продукт согласован с советом директоров и генеральным директором, то затем его передают в СМИ.

Рисунок 3.33. Форма «Создание рекламного продукта»

.4 Построение автоматизированного процесса «Снятие объекта с охраны»

В результате анализа во второй главе, в данном процессе были выделены следующие роли:

.        Клиент.

.        Активный менеджер.

.        Начальник коммерческого отдела.

.        Коммерческий директор.

.        Инженер технического отдела.

Связи ролей и отношений показаны на рисунке 3.34.

Рисунок 3.34. Роли и отношения

Все необходимые для работы переменные указаны на рисунке 3.35.

Рисунок 3.35. Переменные в бизнес-процессе «Снятие объекта с охраны»

Процесс создания и настройки системы идентичен процессу, описанному выше в п. 3.1, поэтому подробное описание здесь будет опущено.

Процесс снятия объекта с охраны начинается с заявки клиента. Форма приема заявки представлена на рисунке 3.36.

Рисунок 3.36. Форма «Прием заявки»

После подачи заявки клиентом, ее принимает активный менеджер и составляет акт о снятии объекта с охраны. Форма для выполнения данного задания представлена на рисунке 3.37.

Рисунок 3.37. Форма «Прием заявки и составление акта о снятии объекта с охраны»

Затем активным менеджером передается акт на согласование и подпись начальнику коммерческого отдела и коммерческому директору. Форма выполнения данного задания представлена на рисунке 3.38.

Рисунок 3.38. Форма «Передача документа на согласование и подпись»

Форма выполнения согласования и подписи акта начальником коммерческого отдела и коммерческим директором аналогична и представлена на рисунке 3.39.

Рисунок 3.39. Форма «Согласование и подпись документа»

После согласования и подписи акта активным менеджером составляется заявка на демонтаж оборудования и затем передается инженеру технического отдела. Форма выполнения данной задачи показана на рисунке 3.40.

Рисунок 3.40. Форма «Составление заявки на демонтаж оборудования»

На рисунке 3.41 представлена форма приема заявки на демонтаж оборудования.

Рисунок 3.41. Форма «Прием заявки»

После приема заявки на демонтаж оборудования, инженерами технического объекта выполняется поставленная перед ними задача. Форма выполнения данной задачи представлена на рисунке 3.42.

Рисунок 3.42. Форма «Демонтаж оборудования на объекте»

После выполнения работ инженером технического отдела составляется отчет о выполненных работах. Форма выполнения задачи показана на рисунке 3.43.

Рисунок 3.43. Форма «Составление отчета о выполненных работах»

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

Рисунок 3.44. Форма «Подписание акта и снятие объекта с охраны»

Заключение

В результате выполнения данной курсовой работы были рассмотрены и проанализированы два бизнес-процесса, происходящие внутри коммерческого отдела группы предприятий «Цербер»: «Постановка объекта на охрану» и «Создание рекламной продукции». Были рассмотрены и изучены необходимые регламенты и положения, необходимые для регулирования работы данных бизнес-процессов.

В результате анализа существующих нотаций были получены новые сведения о данных нотациях. Для данной работы была выбрана нотация BPMN 2.0, т.к. она удовлетворяла критериям, поставленным для решения задачи. В качестве средства моделирования был выбран бесплатно распространяемый программный продукт «Bizagi Modeler». На основе анализа имеющихся данных были построены модели бизнес-процессов. В дальнейшем был выполнен анализ бизнес-процессов с помощью имитационного моделирования. В результате симуляции были выявлены недостатки бизнес-процессов. В дальнейшем планируется изменить модели для уменьшения временных и денежных затрат и построить на их основе автоматизированную систему. На следующем этапе работы были построены прототипы системы управления бизнес-процессами. Выполнение данного этапа работы позволило провести анализ управления бизнес-процессами и оценить качество выполненных моделей на предыдущем этапе работы. В результате сравнительного анализа для создания прототипов была выбрана программа «RunaWFE». Качество построенных моделей оказались на достаточно высоком уровне, так как для создания прототипа потребовались незначительные изменения, которые никак не повлияли на читаемость и понимание модели.

Полученные модели можно использовать для дальнейшей оптимизации бизнес-процессов коммерческого отдела группы предприятий «Цербер».

Библиографический список

1.            IDEF0 нотация. [Электронный ресурс] // URL https://ru.wikipedia.org/wiki/IDEF0 (дата обращения: 25.03.2017)

2.       Методология IDEF3. [Электронный ресурс] // URL #»907858.files/image038.jpg»>

Рисунок А.1. Модель бизнес-процесса «Прием объекта на охрану»

Приложение В. Модель процесса «Создание рекламной продукции»

Рисунок В.1. Модель бизнес-процесса «Создание рекламной продукции»

Приложение C. Модель процесса «Снятие объекта с охраны»
Рисунок С.1. Модель бизнес-процесса «Снятие объекта с охраны»