Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Построение модели бизнес-процессов департамента в BPMN

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

Ознакомление с основными принципами выбора BPM-системы для автоматизации бизнес-процессов. Построение и анализ прототипа системы, автоматизирующей учебные процессы. Характеристика особенностей Bonita Open Solution – французского программного решения.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 01.09.2017
Размер файла 1,7 M
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

390 мин

630 мин

Согласование начальником отдела организации учебного процесса

10 мин

0 мин

0 мин

130 мин

0 мин

0 мин

170 мин

0 мин

0 мин

Согласование начальником координации

10 мин

0 мин

0 мин

130 мин

0 мин

0 мин

130 мин

0 мин

0 мин

Принятие решение проректором

10 мин

0 мин

0 мин

130 мин

0 мин

0 мин

130 мин

0 мин

0 мин

Сообщить решение проректора

5 мин

0 мин

0 мин

5 мин

0 мин

0 мин

201.25 мин

71.25 мин

130 мин

Подготовить приказ

17.85 мин

2.85 мин

20 мин

138.57 мин

3.57 мин

25 мин

136 мин

1 мин

5 мин

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

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

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

Исполнитель/

Сценарий

Сценарий 1

Сценарий 2

Сценарий 3

Специалист отдела по сопровождению учебного процесса

2 491

7 191

10 575

Члены аттестационной комиссии (4 человека)

10 500

26 250

32 500

Декан

4 083

9 508

8 083

Сотрудник общего отдела

219

3 258

4 684

Специалист учебного отдела

219

3 258

4 684

Юрист

327

4 566

4 987

Бухгалтер

327

4 566

4 987

Заместитель директора

910

13 520

18 590

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

583

9 208

10 000

Начальник отдела координации работы со студентами

583

9 208

10 000

Проректор

1 872

24 342

34 775

Общие затраты

22 117

341 703

429 116

Большое количество заявок, подаваемых в короткие промежутки, ведет к резкому увеличению стоимости процесса. Затраты в третьем сценарии получились почти на 50% выше, несмотря на тот факт, что из 10 заявок, поданных специалисту учебного офиса, 2 были сразу отклонены по причине отсутствия мест. При условиях третьего сценария возникают узкие места при переаттестации и согласовании документов деканом. Это связано с тем, что декан участвует в обоих процессах и когда он занят в одном из них, то не может выполнить другой.

2.2.3 Выводы по результатам симуляции

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

2.3 Построение модели бизнес-процесса «Предоставление скидок по оплате обучения по результатам обучения»

2.3.1 Анализ бизнес-процесса

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

Владелец бизнес-процесса: заместитель директора НИУ ВШЭ-Пермь Архипов Валерий Михайлович.

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

Студент.

Сотрудники отдела по сопровождению учебного процесса.

Декан факультета.

Сотрудники учебного отдела.

Главный бухгалтер НИУ ВШЭ-Пермь.

Сотрудники общего отдела.

Заместитель директора НИУ ВШЭ-Пермь.

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

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

Операции бизнес-процесса и их исполнители:

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

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

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

Декан проверяет правильность заполнения документов и согласовывает их. В случае отсутствия замечаний пакет документов передается начальнику учебного отдела НИУ ВШЭ-Пермь, в противном случае документы возвращаются в учебный офис для устранения замечаний.

Начальник учебного отдела проверяет правильность заполнения документов и согласовывает их. В случае отсутствия замечаний пакет документов передается главному бухгалтеру НИУ ВШЭ-Пермь, в противном случае документы возвращаются в учебный офис для устранения замечаний.

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

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

Заместитель директора НИУ ВШЭ-Пермь принимает решение о предоставлении студенту скидки на оплату обучения. Свое решение он отсылает в учебный офис.

Учебный офис уведомляет студента о решении заместителя директора.

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

Студент должен подать заявку на предоставление скидки в течение 10 дней с момента публикации рейтинга студентов по итогам третьего и четвертого модулей до пересдач на сайте НИУ ВШЭ-Пермь в случае отсутствия неявок без уважительных причин и неудовлетворительных результатов промежуточной аттестации в третьем или четвертом модулях.

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

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

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

Наличие у студента академической задолженности.

Наличие у студента дисциплинарных взысканий.

Наличие более двух оценок ниже 6 баллов по десятибалльной шкале.

Наличие оценок ниже 4 баллов по десятибалльной шкале.

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

Студент входит в 10% всех студентов курса; студент входил в первые 10% всех студентов курса по текущему рейтингу до пересдач.

Студент входит в первые 15% всех студентов курса по сумме двух последних текущих рейтингов.

Студент входит в первые 25% всех студентов курса по сумме двух последних текущих рейтингов.

Студент входит в первые 50% всех студентов курса по сумме двух последних текущих рейтингов.

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

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

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

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

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

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

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

Рейтинг успеваемости студента.

Заявление на скидку.

Приказ о предоставлении скидки.

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

Рисунок 2.2. Организационная структура

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

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

Операция \ Сотрудник

Отдел по сопровождению учебного процесса

Декан факультета

Учебный отдел

Бухгалтерия

Общий отдел

Заместитель директора НИУ ВШЭ-Пермь

Проверить заявление студента

+

-

-

-

-

-

Собрать данные о студенте

+

-

-

-

-

-

Проверить наличие права на скидку

+

-

-

-

-

-

Согласование

-

+

+

+

+

-

Принять решение о предоставлении скидки

-

-

-

-

-

+

Сообщить студенту о решении заместителя директора

+

-

-

-

-

-

Матрица денежных и временных затрат на выполнение операции представлена в табл. 2.11.

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

Операция

Среднее время выполнения

Стоимость

Проверить заявление студента

5 минут

5 рублей

Собрать данные о студенте и проверить наличие права на скидку

20 минут

50 рублей

Отправить на согласование

5 минут

5 рублей

Согласование

15 минут

25 рублей

Исправление замечаний

15 минут

25 рублей

Принять решение о предоставлении скидки

10 минут

25 рублей

Получить решение заместителя директора и передать его студенту

5 минут

5 рублей

На табл. 2.12 представлены зарплаты исполнителей, участвующих в бизнес_процессе.

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

Исполнитель

Заработная плата в месяц

Почасовая оплата

Специалист отдела по сопровождению учебного процесса

30 000 руб.

188 руб.

Декан

80 000 руб.

500 руб.

Сотрудник общего отдела

30 000 руб.

188 руб.

Специалист учебного отдела

30 000 руб.

188 руб.

Бухгалтер

45 000 руб.

281 руб.

Заместитель директора НИУ ВШЭ-Пермь

100 000 руб.

568 руб.

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

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

Операция \ Сотрудник

Скидка 100%

Скидка 70%

Скидка 50%

Скидка 25%

Отказ

Проверить заявление студента

-

-

-

-

-

Собрать данные о студенте

-

-

-

-

-

Проверить наличие права на скидку

-

-

-

-

+

Согласование

-

-

-

-

-

Принять решение о предоставлении скидки

+

+

+

+

+

Сообщить студенту о решении заместителя директора

-

-

-

-

-

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

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

Бизнес-условие \ Бизнес-событие

Скидка 100%

Скидка 70%

Скидка 50%

Скидка 25%

Отказ

Наличие у студента академической задолженности

-

-

-

-

+

Наличие у студента дисциплинарных взысканий

-

-

-

-

+

Наличие более двух оценок ниже 6 баллов по десятибалльной шкале

-

-

-

-

+

Наличие оценок ниже 4 баллов по десятибалльной шкале

-

-

-

-

+

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

-

-

-

-

+

Студент входит в 10% всех студентов курса

+

+

-

-

-

Студент входил в первые 10% всех студентов курса по текущему рейтингу до пересдач

+

-

-

-

-

Студент входит в первые 15% всех студентов курса по сумме двух последних текущих рейтингов

-

+

-

-

-

Студент входит в первые 25% всех студентов курса по сумме двух последних текущих рейтингов

-

-

+

-

-

Студент входит в первые 50% всех студентов курса по сумме двух последних текущих рейтингов

-

-

-

+

-

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

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

Операции БП \ Документы, БД

Рейтинг студента

Заявление на скидку

Приказ о предоставлении скидки

Положение о предоставлении скидки

Проверить заявление студента

-

+

-

-

Собрать данные о студенте

+

-

-

-

Проверить наличие права на скидку

+

-

-

+

Согласование

+

+

-

+

Принять решение о предоставлении скидки

-

-

-

+

Сообщить студенту о решении заместителя директора

-

-

-

-

2.3.2 Симуляция бизнес-процесса

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

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

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

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

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

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

Количество сотрудников учебного офиса - 3.

Количество сотрудников учебного отдела - 3.

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

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

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

Ожидания проверки заявления и отправки на согласование нет.

Ожидание сбора данных - 10 мин.

Согласование деканом - 2 часа, заместителем директора - 3 часа.

Сообщение студенту решения директора - 30 мин.

Отправить на согласование остальным - 1 час.

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

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

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

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

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

Ожидания проверки заявления и отправки на согласование нет.

Ожидание сбора данных - 10 мин.

Согласование деканом - 2 часа, заместителем директора - 3 часа, бухгалтером - 1 час 30 мин.

Ожидание исправления замечаний - 1 час.

Сообщение студенту решения директора - 30 мин.

Отправить на согласование остальным - 1 час.

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

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

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

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

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

Ожидания проверки заявления и отправки на согласование нет.

Ожидание сбора данных - 2 часа.

Согласование деканом - 2 часа, заместителем директора - 3 часа, бухгалтером - 1 час 30 мин.

Ожидание исправления замечаний - 2 часа.

Сообщение студенту решения директора - 30 мин.

Отправить на согласование остальным - 1 час.

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

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

Всех исполнителей шагов бизнес-процесса по одному.

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

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

Операция/Сценарий

Сценарий 1

Сценарий 2

Сценарий 3

Сценарий 4

Среднее время выполнения для одного экземпляра

3 ч 46 мин

28 ч 40 мин

21 ч 29 мин

44 ч 6 мин

Количество экземпляров

15

15

10

10

Проверить и принять заявление

21.2 мин

16.2 мин

47 мин

5 мин

0 мин

0 мин

5 мин

0 мин

0 мин

176.5 мин

171.5 мин

850 мин

Проверить данные студента

58 мин

38 мин

57 мин

30 мин

0 мин

0 мин

30 мин

0 мин

0 мин

581.5 мин

441.5 мин

855 мин

Отправить на согласование

42 мин

37 мин

59 мин

5 мин

0 мин

0 мин

12 мин

7 мин

70 мин

558 мин

553 мин

1000 мин

Согласование деканом

42 мин

37 мин

59 мин

895 мин

760 мин

1530 мин

352 мин

217 мин

405 мин

581 мин

446 мин

880 мин

Согласование учебным отделом

15 мин

0 мин

0 мин

77 мин

2 мин

35 мин

189 мин

54 мин

135 мин

80 мин

5 мин

40 мин

Согласование главным бухгалтером

15 мин

0 мин

0 мин

79 мин

4 мин

35 мин

161 мин

31 мин

135 мин

149 мин

44 мин

150 мин

Согласование общим отделом

15 мин

0 мин

0 мин

77 мин

2 мин

35 мин

189 мин

54 мин

135 мин

80 мин

5 мин

40 мин

Принятие решение заместителем директора

10 мин

0 мин

0 мин

527 мин

337 мин

755 мин

316 мин

126 мин

260 мин

375 мин

185 мин

460 мин

Получить решение и отослать студенту

5.5 мин

0.5 мин

7 мин

35 мин

0 мин

0 мин

35 мин

0 мин

0 мин

65 мин

35 мин

90 мин

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

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

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

Исполнитель /Сценарий

Сценарий 1

Сценарий 2

Сценарий 3

Сценарий 4

Отдел по сопровождению учебного процесса

2 115

4 026

4 104

9 306

Декан

1875

19 125

13 500

14 625

Учебный отдел

937

5000

6 187

3 437

Главный бухгалтер

1 402

7 947

10 098

7 854

Общий отдел

937

1 200

6 750

3 750

Заместитель директора

1 950

37 050

24 700

24 700

Общие затраты

9 218

74 348

65 340

63 672

2.3.3 Выводы по результатам симуляции

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

В рамках работ по анализу и моделированию в Bizagi Modeler бизнес-процессов «Восстановление студента, отчисленного по собственному желанию, по инициативе НИУ ВШЭ или выход из академического отпуска» и «Предоставление скидок по оплате обучения по результатам обучения» были выполнены следующие действия:

· Изучены регламенты бизнес-процессов.

· Определены последовательности действий и возможные переходы бизнес_процессов.

· Определён список участников бизнес-процессов и их зоны ответственности

· Построены схемы бизнес-процессов в нотации BPMN.

· Определены сценарии для моделирования.

· Выполнено моделирование бизнес-процессов.

· Проведён анализ результатов.

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

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

3.1 Понятие исполнимого процесса

Автоматизация процессов является неотъемлемой частью процессного подхода к управлению организацией. Любой исполнимый процесс, модель которого будет загружена на сервер системы управления бизнес-процессами, имеет четыре перспективы или точек зрения [3].

Первая перспектива - перспектива потока управления, которая соответствует схеме бизнес-процесса. Бизнес-процесс рассматривается как множество соединённых узлов. Существует три категории узлов:

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

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

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

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

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

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

Четвертая перспектива - перспектива операций. Она соответствует набору операций, который исполнитель выполняет в узле-действии. Инструментом для выполнения операций является визуальная форма, которая появляется перед исполнителем в момент передачи точки управления на его узел [2]. В отличие от трех предыдущих перспектив, модели, реализованные во второй главе, не позволяет изучить процессы в этом срезе. Для рассмотрения процесса с этой перспективы будут спроектированы web-формы в конструкторе форм RunaWFE, с которыми сотрудники будут взаимодействовать для выполнений операций.

3.2 Построение прототипа автоматизированного процесса «Восстановление студента, отчисленного по собственному желанию, по инициативе НИУ ВШЭ или выход из академического отпуска»

Работа по построению прототипа начинается с построения модели процесса в графическом редакторе RunaWFE. К сожалению, процесс переноса моделей из Bizagi Modeler в RunaWFE Process Designer оказался невозможным, поэтому пришлось перерисовать модель заново в новом редакторе. Модель бизнес-процесса была незначительно упрощена в связи с особенностью инструмента RunaWFE, что не изменяет модель в целом и не усложнит её понимание читателям, но позволит облегчить процесс построения системы. Части процесса, связанные с согласованием документов, которые выглядели в Bizagi Modeler так, как изображено на рис. 3.1, в RunaWFE Process Designer будут представлены так, как на рис. 3.2.

Рисунок 3.1. Процесс согласования в модели Bizagi Modeler.

Рисунок 3.2. Процесс согласование в RunaWFE Process Designer.

Следующим этапом работы, выполненным после переноса модели, являлось занесение ролей в RunaWFE. Это было реализовано в двух местах: RunaWFE Process Designer и Simulation web interface. Для создания ролей в редакторе необходимо было внести информацию в одноимённую вкладку, представленную на рис. 3.3.

Рисунок 3.3. Вкладка «Роли» в Process Designer.

Для процесса «Восстановление студента, отчисленного по собственному желанию, по инициативе НИУ ВШЭ или выход из академического отпуска» во второй главе были выявлены следующие роли (в порядке их задейстования):

Студент.

Сотрудники отдела по сопровождению учебного процесса.

Аттестационная комиссия.

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

Декан факультета.

Сотрудники общего отдела.

Сотрудники учебного отдела.

Юридический отдел.

Главный бухгалтер НИУ ВШЭ-Пермь.

Заместитель директора НИУ ВШЭ-Пермь.

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

Начальник отдела координации по работе со студентами.

Проректор.

Далее необходимо создать аналогичные группы в веб-интерфейсе. Для этого необходимо во вкладке «Исполнители» создать одноимённые группы, в которые потом будут включаться пользователи. На рис. 3.4 представлена страница создания группы, а на рис. 3.5 представлена страница для создания пользователя. Потом необходимо включить пользователя в необходимую группу.

Рисунок 3.4. Создание группы в веб-интерфейсе RunaWFE.

Рисунок 3.5. Создание пользователя в веб-интерфейсе.

Для связи групп пользователей в процессе необходимо задать отношения. Это реализуется через одноимённую вкладку в веб-интерфейсе. На рис. 3.6 изображен пример создания отношения между группами. Отношение можно создать только между двумя группами, при этом включенные группы могут включать в себя другие подгруппы. Для связи ролей в Process Designer и группы в веб-интерфейсе необходимо их инициализатора роли, как изображено на рис. 3.7.

Рисунок 3.6. Создание отношений.

Рисунок 3.7. Связывание ролей веб-интерфейса и роли в Process Modeler.

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

Рисунок 3.8. Список переменных процесса.

После инициализации переменных необходимо задать ограничения и проверки. Например сделаем так, чтобы сканированная копия заявления студента могла быть только в формате pdf, jpg и jpeg. Для этого в окне проверки переменных формы укажем это ограничение (см. рис. 3.9).

Рисунок 3.9. Проверка формата файла.

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

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

Рисунок 3.10. Шаблон веб-формы в конструкторе.

Рисунок 3.11. Веб-форма.

После выполнения работ по постройке процесса в RunaWFE необходимо протестировать его работу. Зайдем в систему под пользователем группы «Студенты» Старковым и запустим процесс его восстановления, как изображено на рис. 3.12.

Рисунок 3.12. Запуск экземпляра бизнес-процесса.

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

Рисунок 3.13. Форма, извещающая об отрицательном ответе.

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

Рисунок 3.14. Конфигурация исключающего шлюза.

Глава аттестационной комиссии Авраменко получает заявку на загрузку протокола заседания комиссии. После его обсуждения с другими членами, он загружает итоговый подписанный протокол в систему. Форма работы представлена на рис. 3.15.

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

Рисунок 3.15. Форма работы главы аттестационной комиссии.

Рисунок 3.16. Форма ознакомления студента с протоколом комиссии.

Следующим этапом работ является создание ИУП студента на основе протокола аттестационной комиссии специалистом учебного офиса. После создания ИУП его необходимо загрузить в систему для его утверждения руководителем образовательной программы. Форма работы изображена на рис. 3.17.

Рисунок 3.17. Веб-форма для загрузки ИУП.

Если студент восстанавливается на коммерческой основе, работа перейдет к специалисту учебного офиса. Он составляет договор об оказании платных образовательных услуг на основе ИУП, загружает его и передает на согласование сотруднику общего отдела. Если студент восстанавливается на бюджетную форму обучения, то после ознакомления с ИУП он сразу передаётся в общий отдел. За переход по каждой из ветвей отвечает логическая переменная «Восстановление на коммерческой основе». Форма для загрузки договора представлена на рис. 3.18.

Рисунок 3.18. Загрузка договора.

Далее идёт согласование документов следующими лицами:

Сотрудники общего отдела.

Декан факультета.

Сотрудники учебного отдела.

Юридический отдел.

Главный бухгалтер НИУ ВШЭ-Пермь.

Заместитель директора НИУ ВШЭ-Пермь.

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

Начальник отдела координации по работе со студентами.

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

Рисунок 3.19. Форма согласования.

Рисунок 3.20. Форма устранения замечаний

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

Рисунок 3.21. Форма принятия решения ректором.

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

Рисунок 3.22. Форма загрузки квитанции.

Рисунок 3.23. Форма загрузки приказа.

В RunaWFE можно посмотреть течение каждого экземпляра процесса, посмотреть кто и когда выполнил шаг процесса. Для этого надо выбрать нужный экземпляр во вкладке «Запущенные процессы». Пример можно увидеть на рис. 3.24.

Рисунок 3.24. Информация о шаге процесса.

3.3 Построение прототипа автоматизированного процесса «Предоставление скидок по оплате обучения по результатам обучения»

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

Студент.

Сотрудники отдела по сопровождению учебного процесса.

Декан факультета.

Сотрудники учебного отдела.

Главный бухгалтер НИУ ВШЭ-Пермь.

Сотрудники общего отдела.

Заместитель директора НИУ ВШЭ-Пермь.

Связи ролей и отношений, построенных в RunaWFE, представлены на рис. 3.25.

Рисунок 3.25. Связи ролей и отношений процесса.

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

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

Рисунок 3.26. Форма для подачи заявления.

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

Рисунок 3.27. Форма работы специалиста учебного офиса.

Далее идёт процесс согласования по следующему порядку:

Декан факультета.

Сотрудники учебного отдела.

Главный бухгалтер НИУ ВШЭ-Пермь.

Сотрудники общего отдела.

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

Рисунок 3.28. Форма согласования.

Заместитель директора НИУ ВШЭ-Пермь принимает решение о предоставлении скидки после согласования. После этого студент получает решение заместителя директора вне зависимости от того, положительное оно или нет. Формы работы заместителя директора и студента представлены на рис. 3.29 и рис. 3.30.

Рисунок 3.29. Форма работы заместителя директора НИУ ВШЭ-Пермь.

Рисунок 3.30. Форма извещения студента.

Рисунок 3.31. Список переменных, задействованных в процессе.

На рис. 3.32 отображены все данные процесса, значением переменных и участников. На рис. 3.31 указаны все переменные, задействованные в данном процессе.

Рисунок 3.32. Данные об экземпляре процесса.

Рисунок 3.33. Отображение переходов процесса.

Заключение

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

В результате анализа программ для построения моделей бизнес_процессов была выбрана программа «Bizagi Modeler». На основе изученных регламентов этих бизнес-процессов были построены и просимулированы исполняемые модели.

С помощью этих моделей удалось определить узкие места бизнес-процессов и условия их появления. В случае процесса «Восстановление студента, отчисленного по собственному желанию, по инициативе НИУ ВШЭ или выход из академического отпуска» это шаги, связанные с работой декана. В процессе «Предоставление скидок по оплате обучения по результатам обучения» это шаги, связанные с согласованием документов.

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

Полученные в результате построения в «Bizagi Modeler» модели можно использовать, во-первых, как начальную точку при изменении и оптимизации бизнес-процессов «Восстановление студента, отчисленного по собственному желанию, по инициативе НИУ ВШЭ или выход из академического отпуска» и «Предоставление скидок по оплате обучения по результатам обучения» а во-вторых для автоматизации указанных процессов. Построенный в «RunaWFE» прототип может стать отправной точной для создания системы автоматизированных бизнес-процессов в НИУ ВШЭ.

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

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

1. ELMA - Система управления бизнес- процессами и эффективностью. [Электронный ресурс] // ELMA - URL: https://www.elma-bpm.ru/help/Platform/content/Designer_Architecture_ELMA_index.html (дата обращения: 28.04.2017).

2. Гётц М. Моделирование технологического процесса через перспективу потока управления, используя BPMN и Средство моделирования BPM Bizagi / пер с англ. - М.: ДМК Пресс, 2009. - 51 с.

3. Документация RunaWFE. [Электронный ресурс] // Проект RunaWFE - URL: http://www.runawfe.org/rus/%D0%9E_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5 (дата обращения: 25.04.2017].

4. Информационное пространство по вопросам использования BPMN. [Электронный ресурс] // BPMN Specification - URL: http://www.bpmn.org (дата обращения: 28.04.2017).

5. Кулябов Д.С., Королькова А.В. Введение в формальные методы описания бизнес-процессов: Учеб.пособие. - М.: РУДН, 2008. - 173 с.

6. Руководство пользователя «Bizagi Process Modeler». [Электронный ресурс] // Bizagi Modeler User's Guide - URL: http://download.bizagi.com/docs/modeler/2511/en/ Modeler_user_Guide.pdf] (дата обращения 28.04.2017).

7. Сравнительный обзор BPM-систем [Электронный ресурс] // Хабрахабр - URL: https://habrahabr.ru/post/221495 (дата обращения: 28.04.2017)

Приложение

Модель процесса «Получение скидки по результатам обучения» в нотации BPMN.

Размещено на Allbest.ru

...

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены