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

12

15

51

31,25

375

16,25

Визирование заявлений

10

7

41

19,6

196

17,6

Составление материалов для работы комиссии

10

24

55

35,4

354

15,4

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

10

2

2

2

20

0

Составление приказа о переходе студентов

10

10

45

21,3

213

11,3

Размещения протокола на сайте НИУ ВШЭ

10

4

5

4,5

45

0,5

Заседание комиссии

10

60

64

60,4

604

0,4

Передача выписки заседания студсовета комиссии

10

5

12

7

70

2

Решение принимает заседатель комиссии

1

9

9

9

9

0

Утверждение состава комиссии

10

5

5

5

50

0

Заседание студенческого совета

10

60

85

66,4

664

6,4

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

Общее «чистое» время выполнения бизнес-процесса составило 2,49 дня. Под «чистым» временем подразумевается, время, потраченное только на выполнение задач, без учета сроков и ожидания определенной даты.

Как видно из таблицы, процессами с самым высоким показателем среднего времени выполнения являются: заседание студенческого совета и заседание комиссии, но отклонение от минимального времени (определенного ранее) у них низкое. Стоит обратить внимание на отклонение процесса подачи документов в учебный офис и проверки полученных заявок - 17,33 и 16,25 минут соответственно. Их среднее время выполнения гораздо выше запланированного, что говорит о том, что работник не успевает закончить работу над другими процессами так, чтобы вовремя приступить к работе над следующими. То же самое можно сказать и про процесс составления материалов для работы комиссии и составления приказа о переходе студентов. Как и предполагалось ранее на этапе анализа, руководитель учебного офиса перегружен объемом задач в данном бизнес-процессе.

Также в результате имитационного эксперимента были определены денежные затраты НИУ ВШЭ на заработные платы сотрудникам, участвующим в процессе (таблица 2.6). Эти данные будут использоваться в дальнейшем для сравнения с результатами модели To Be.

Таблица 2.6 - Финансовые затраты на выполнение процесса As Is

Ресурс	Использование	Фиксированная стоимость	Затраты на почасовую оплату	Общие затраты
Студент	63,32%	0	0	0
Руководитель учебного офиса	76,46%	0	5000	5000
Ректор НИУ ВШЭ	8,36%	0	1458,33	1458,33
Комиссия	78,14%	0	8175	8175
Студенческий совет	71,68%	0	0	0



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

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

2.3.3 Построение процесса To Be

Построение модели To Be проходило под руководством следующих принципов:

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

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

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

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

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

Измененные показатели временных затрат процессов приведены в таблице ниже (таблица 2.7).

Таблица 2.7 - Длительность выполнения каждой операции процесса As Is

№	Операция	Длительность выполнения, минут
1	Подача документов в единую систему	10
4	Размещение информации о количестве свободных мест на сайте	5
5	Проверка полученных заявок	5
6	Визирование заявлений	2
7	Составление материалов для работы комиссии	10
8	Утверждение состава комиссии	5
9	Заседание студенческого совета	30
10	Передача выписки комиссии	5
11	Заседание комиссии	30
12	Принятие решения заседателем комиссии	4
13	Размещения протокола на сайте НИУ ВШЭ	2
14	Составление приказа о переходе студентов	2
15	Подписание приказа	2

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

2.3.4 Имитация процесса To Be

При имитации процесса To Be, на вход будут также как и при эксперименте с процессом As Is в целях наиболее точного сравнения. Измененная модель представлена в Приложении Б. Результаты проведенного имитационного эксперимента приведены в таблице ниже (см. таблицу 2.8).



Таблица 2.8 - Результаты симуляции процесса To Be

Процесс	Выполнено	Мин. Время (мин)	Макс. Время (мин)	Ср. время (мин)	Время всего (мин)	Среднее время ожидания (мин)
Переход студента с платного на бесплатное обучение	10	113	386	259,3	1381,3
Размещение информации о количестве мест на сайте	10	5	17	11	110	6
Подача документов в единую систему	10	15	20	17,1	171	57
Проверка полученных заявок	10	5	10	5,7	57	0,7
Визирование заявлений	10	2	2	2	20	0
Составление материалов для работы комиссии	10	10	10	10	100	0
Подписание приказа	10	2	2	2	20	0
Составление приказа о переходе студентов	10	2	2	2	20	0
Размещения протокола на сайте НИУ ВШЭ	10	2	2	2	20	0
Заседание комиссии	10	30	42	35,2	352	5,2
Решение принимает заседатель комиссии	3	34	38	35,33	106	31,33
Утверждение состава комиссии	10	5	6	5,2	52	0,2
Заседание студсовета	10	30	40	35,33	353,3	5,33

Как можно заметить, общее время выполнения процесса снизилось более чем в два раза и составило 1381 минуту, что говорит о значительной оптимизации бизнес-процесса. Для более наглядного сравнения был построен график, сопоставляющий время выполнения каждого процесса в модели As Is и в модели To Be (см. рис. 2.6).

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

Рисунок 2.6 Сравнительный график имитационных моделей

В результате имитационного эксперимента с моделью To Be также были сформированы величины затрат НИУ ВШЭ на заработную плату исполнителям процесса (таблица 2.9).

Таблица 2.9 - Финансовые затраты на выполнение процесса To Be

Ресурс	Использование	Фиксированная стоимость	Затраты на почасовую оплату	Общие затраты
Студент	37,97%	0	0	0
Руководитель учебного офиса	70,12%	0	2031,25	2031,25
Ректор НИУ ВШЭ	17,72%	0	1458,33	1458,33
Комиссия	65,84%	0	3900	3900
Студенческий совет	65,81%	0	0	0

Таким образом, затраты на выполнение бизнес-процесса уменьшились почти в 2 раза и составили 7389,58 рублей, а если учесть, что процесс происходит четыре раза в год, то снижение годовой стоимости бизнес-процесса составило 28975 рублей в расчете на то, что количество заявок будет составлять 10 штук.

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

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

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

Возможность проведения заседаний студенческого совета и комиссии в системе управления в онлайн-режиме;

Проверка системой поступающих от студентов заявок и последующее их формирование в единую базу для работы комиссии;

Оповещение студентов о важных этапах выполнения процесса;

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

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



Глава 3. Разработка системы управления

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

3.1 Проектирование организационной структуры

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

Набор ролей в Developer Studio (см. рис. 3.1) соответствуют описанному ранее в работе, за исключением того, что роли «Студенческий совет» и «Комиссия» разбиты на отдельные роли членов и председателя комиссий.

Рисунок 3.1 Роли бизнес-процесса

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

Таблица 3.1. Организационная структура системы управения

Группа	Подгруппа	Исполнитель
Студенты	Студенты бизнес-информатики	Петров Андрей Иванович
	Студенты программной инженерии	Надымов Савелий Александрович
	Студенты менеджмента	Веневцев Василий Глебович
	Студенты экономики	Романенко Глеб Викторович
	Студенты юриспруденции	Лобанов Семён Семёнович
Учебные офисы	Бизнес-информатика	Васильев Александр Игоревич
	Программная инженерия	Звездов Роман Михайлович
	Менеджмент	Букина Светлана Геннадиевна
	Экономика	Шабадинова Лена Викторовна
	Юриспруденция	Земляникин Григорий Григорьевич
Студенческий совет	Председатель студсовета	Шелевят Вадим Сергеевич
	Члены студсовета	Онферов Александр Витальевич
		Пынин Федор Николаевич
Комиссия	Председатель комиссии	Быков Андрей Евгеньевич
	Члены комиссии	Купитман Иван Георгиевич
		Левин Борис Аркадиевич
		Воронин Николай Петрович

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



3.2 Проектирование модели процесса

Следующим шагом в разработке системы управления будет создание BPMN модели бизнес-процесса в RunaWFE Developer Studio, основанной на модели, построенной в Bizagi Modeler. Построенная модель приведена в приложении (см. приложение В).

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

Рисунок 3.2 Фрагмент модели бизнес-процесса.

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

Рисунок 3.3 Редактор формы «Отправка заявления»

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

3.3 Проектирование форм системы

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

3.3.1 Форма «Отправка заявления»

При запуске процесса, появляется активная задача «Отправка заявления» (см. рис.3.4), которую может начать только пользователь группы «Студенты».

Рисунок 3.4 Активная задача «Отправка заявления»

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

Рисунок 3.5 Форма «Отправка заявления»

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

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

3.3.2 Форма «Проверка заявки»

После формирования заявления, у руководителя учебного офиса появляется задача «Проверка заявки», при входе в которую он видит следующую форму (см. рис. 3.6). Там он может скачать сформированное заявление, проверить его на корректность и, согласно модели, либо визировать её, либо отправить студенту на редактирование.

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

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

Рисунок 3.7 Редактор формы «Проверка заявки»



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

3.3.3 Форма «Утверждение состава комиссии»

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

Рисунок 3.7 Исполнитель, назначенный в группу «Комиссия»

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



3.3.4 Форма «Формирование мнения студенческого совета»

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

Рисунок 3.8 Форма «Формирование мнения студенческого совета»

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

3.3.5 Форма «Формирование мнения комиссии»

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

Рисунок 3.9 Форма «Формирование мнения комиссии»

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

Рисунок 3.10 Форма «Решение комиссии»

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

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



Заключение

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

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

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



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

1. Фёдоров И. Г. Моделирование бизнес-процессов в нотации BPMN2.0: Монография, Москва 2013 г. МЭСИ. - 255 стр.

2. Iyamu, T. (2017). Understanding the Complexities of Enterprise Architecture through Structuration Theory. Journal of Computer Information Systems, 1-9.

3. О.Д. Глод Архитектура предприятия: учебное пособие / Южный федеральный университет, 2016. - 93 стр.

4. Gonzalez-Lopez, F., & Bustos, G. (2019). Integration of Business Process Architectures within Enterprise Architecture Approaches, Engineering Management Journal, 1-14.

5. Gonzбlez-Rojas, O., Lуpez, A., & Correal, D. (2017). Multilevel complexity measurement in enterprise architecture models. International Journal of Computer Integrated Manufacturing, 30(12), 1280-1300.

6. Niemi, E., & Pekkola, S. (2015). Using enterprise architecture artefacts in an organisation. Enterprise Information Systems, 11(3), 313-338.

7. Nдrman, P., Johnson, P., & Gingnell, L. (2014). Using enterprise architecture to analyse how organisational structure impact motivation and learning. Enterprise Information Systems, 10(5), 523-562.

8. Bischoff, S., Aier, S., & Winter, R. (2014). Use It or Lose It? The Role of Pressure for Use and Utility of Enterprise Architecture Artifacts. 2014 IEEE 16th Conference on Business Informatics.

9. Dijkman, R., Vanderfeesten, I., & Reijers, H. A. (2014). Business process architectures: overview, comparison and framework. Enterprise Information Systems, 10(2), 129-158.

10. Susan, E., & Robinson, S. A. (1994). Mainstreaming Innovation into Business Process Improvement. Engineering Management Journal, 6(1), 7-11.

11. Meade, L. M., & Rogers, K. J. (Jamie). (2001). Selecting Critical Business Processes: A Case Study. Engineering Management Journal, 13(4), 41-46.

12. Sousa, G. W. L., Van Aken, E. M., & Groesbeck, R. L. (2002). Applying an Enterprise Engineering Approach to Engineering Work: A Focus on Business Process Modeling. Engineering Management Journal, 14(3), 15-24.



Приложение

Имитационная модель As Is

Имитационная модель To Be



Схема процесса в RunaWFE Developer Studio



Шаблоны заявлений

Рисунок Г.1. Шаблон заявления на перевод

Рисунок Г.2. Шаблон первой страницы протокола заседания Студсовета



Рисунок Г.3. Шаблон второй страницы протокола заседания Студсовета

Рисунок Г.4. Шаблон протокола заседания Комиссии



Рисунок Г.5. Шаблон Приказа

Техническое задание

1. Введение

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

2. Основания для разработки

Документы, на основании котрых ведется разработка:

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

Порядок и случаями перехода лиц, обучающихся по образовательным программам среднего профессионального и высшего образования, с платного обучения на бесплатное, утвержденные приказом Министерства образования и науки Российской Федерации от 06.06.2013 № 443

3. Назначение разработки

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

Его функциями являются:

Предоставление руководителям учебных офисов информации о количестве свободных бюджетных мест, поданных заявок;

Составление заявки, протоколов заседаний, приказов на основании имеющихся данных;

Проведение заседания комиссий в рамках системы, в виде онлайн_голосования;

Обеспечение администрирования системы;

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

4. Технические требования

4.1. Требования к системе в целом

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

4.1.1. Требования к структуре и функционированию системы

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

4.1.2. Перспективы развития, модернизации системы

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

4.1.3. Требования к численности и квалификации персонала системы

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

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

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

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

4.1.4 Требования к надежности

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

Осуществлять системой анализ действий пользователя на корректность перед совершением различных операций;

Осуществлять обновление компонентов бизнес-процесса только после завершения всех активных задач;

4.1.4 Требования к эргономике и технической эстетике

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

4.1.5 Требования к защите информации от несанкционированного доступа

Защита информации от несанкционированного доступа должна осуществляться с помощью следующих средств:

Идентификация пользователей по уникальным логину и паролю;

Установка ограниченных полномочий всем пользователям, кроме администратора;

Разграничение доступа пользователей на уровне различных этапов выполнения бизнес-процесса;

Доступ к файловой системе только после одобрения администратором.

4.2. Требования к функциям (задачам), выполняемым системой

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

Поэтапное выполнение описанного бизнес-процесса;

Автоматическое формирование на основе введенных данных Заявки, Приказа и других документов бизнес-процесса;

Контроль отправленных студентами заявок с возможностью отправить на корректировку;

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

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

Возможность управлять правами доступа пользователей;

Вход в систему только по уникальной паре логин-пароль;

Наличие у студента возможности просмотра статуса заявки;

Автоматическое изменение системой количества поданных заявок и свободных бюджетных мест;

Председатель комиссии может видеть голоса других членов комиссии относительно каждого студента.

4.2. Требования к техническому обеспечению

Требования к серверному компьютеру: оъем необходимой оперативной памяти >= 1Гб, свободное место на жестком диске 2Гб, Операционная система - Windows (WinXP и выше), Linux (AltLinux, Debian, Ubuntu, Mint, Fedora), Sun Solaris 10.

Требования к клиентскому компьютеру - должен допускать установку интернет браузера, поддерживающего HTML 4.0

4.3. Требования к информационной и программной совместимости

Реализовывать систему управления необходимо на базе программного пакета RunaWFE, соответственно программирование осуществляется на языке JavaScript. К средствам хранения данных требований не предоставляется.

5. Состав и содержание работ по созданию (развитию) системы

Этапы выполнения работы:

Проектирование модели бизнес-процесса перехода студентов с платного обучения на бесплатное;

Создание ролей и привязка их к группам пользователей на сервере;

Создание необходимых для работы процесса переменных;

Создание файловой системы хранения данных;

Создание исполняемых форм подпроцессов;

Создание необходимых скриптов;

Проектирование шаблонов документов;

Создание учетных записей пользователей на сервере;

Тестирование работы системы.

6. Технико-экономические показатели

Экономическая эффективность формируется на основе проведенного анализа Имитационной модели бизнес-процесса и составляет разницу в затратах на процессы To Be и As Is. Таким образом, эффективность экономических показателей составляет примерно 7389,58 рублей.

7. Требования к документированию

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

8. Порядок контроля и приемки

Необходимо выполнить тестирование системы управление, а именно:

Тест на некорректный ввод текста;

Тест на загрузку некорректных файлов;

Тест заполнения системой шаблонов документов;

Тест подсчета системой количества заявок и свободных мест;

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

Проверка функциональных характеристик: согласно их списку. Интерфейс должен работать в пределах ограничений, описанных в документации.

Приложение Е. Руководство пользователя

Введение

Область применения

Рекомендации данного руководства применяются при:

Опытной эксплуатации;

Испытаниях приемки;

Предварительных испытаниях.

Краткое описание возможностей

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

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

Формирование документов по шаблонам;

Онлайн-заседание комиссии и студенческого совета;

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

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

Уровень подготовки пользователя

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

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

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

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

Порядок и случаями перехода лиц, обучающихся по образовательным программам среднего профессионального и высшего образования, с платного обучения на бесплатное, утвержденные приказом Министерства образования и науки Российской Федерации от 06.06.2013 № 443

Назначение и условия применения

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

Подготовка к работе

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

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

Порядок загрузки данных и программ

Никаких данных и программ загружать не требуется.

Порядок проверки работоспособности

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

Открыть браузер с поддержкой HTML 4.0;

Ввести в адресную строку адрес сервера, предоставленный администратором;

На форме аутентификации ввести логин и пароль, войти в систему;

Убедиться что в окне открылось приложение системы.

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

Описание операций

Выполняемые функции и задачи

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

Автоматическое формирование на основе введенных данных Заявки, Приказа и других документов бизнес-процесса;

Контроль отправленных студентами заявок с возможностью отправить на корректировку;

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

Возможность управлять правами доступа пользователей;

Наличие у студента возможности просмотра статуса заявки;

4.2 Описание операций технологического процесса обработки данных, необходимых для выполнения задач

Задача: «Формирование Заявки»

Условия, при соблюдении которых возможно выполнение операции:

Компьютер пользователя подключен к корпоративной сети;

Пользователь зашел в качестве студента;

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

Основные действия в требуемой последовательности:

Запустить задачу «Подача заявки»;

Зайти на форму задачи, обнаружить заполненные поля;

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

Нажать кнопку «Задание исполнено».

Ресурсы, расходуемые на операцию:

10-30 секунд;

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

Задача «Контроль отправленных заявок»

Условия, при соблюдении которых возможно выполнение операции:

Компьютер пользователя подключен к корпоративной сети;

Пользователь зашел в качестве руководителя учебного офиса;

Имеются заявки, отправленные студентами, еще не прошедшие проверку;

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

Основные действия в требуемой последовательности:

В списке задач выбрать задачу «Проверка заявок»;

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

Провести проверку на корректность заполнения;

Выбрать «Принять» или «Отклонить» в соответствии с решением.

Ресурсы, расходуемые на операцию:

60-120 секунд;

Задача «Заседание комиссии»

Условия, при соблюдении которых возможно выполнение операции:

Компьютер пользователя подключен к корпоративной сети;

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

Руководителем учебного офиса проверены все заявки, которые были поданы в срок;

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

Основные действия в требуемой последовательности:

В списке задач выбрать задачу «Заседание комиссии»;

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

Ознакомиться с числом заявок и свободных бюджетных мест;

Выбрать «Принять» или «Отклонить» в соответствии с решением.

Ресурсы, расходуемые на операцию:

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

Задача «Управление правами доступа пользователей»

Условия, при соблюдении которых возможно выполнение операции:

Компьютер пользователя подключен к корпоративной сети;

Пользователь зашел в качестве администратора или ректора НИУ ВШЭ_Пермь;

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

Основные действия в требуемой последовательности:

В меню выбрать пункт «Исполнители»

Выбрать необходимую группу или конкретного пользователя;

Для редактирования полномочий необходимо поставить галочку напротив соответствующего пункта списка;

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

Нажать кнопку «Применить» по окончании внесения изменений.

Ресурсы, расходуемые на операцию:

30-60 секунд;

Если пользователь вошел в систему в качестве ректора, то ему для редактирования доступны только группы «Комиссия» и «Студенческий совет»

Задача «Просмотр статуса заявки»

Условия, при соблюдении которых возможно выполнение операции:

Компьютер пользователя подключен к корпоративной сети;

Пользователь зашел в качестве студента;

Студентом была отправлена заявка на перевод на бюджетное место;

Заседание комиссии завершилось

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

Основные действия в требуемой последовательности:

Выбрать задачу «Ознакомление со статусом заявки»

Ознакомиться с решением по заявке;

Ресурсы, расходуемые на операцию:

секунд;

5. Аварийные ситуации

При обнаружении каких-либо аварийных ситуаций следует обратиться к администратору системы.

Рекомендации по освоению

Дополнительной литературы для освоения работы с данной системой управления не требуется. При появлении каких-либо вопросов касательно работы системы следует обратиться к администратору.

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

...