2.3.2. Проведение имитационных экспериментов с моделью

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

Рисунок 2.7 - Проверка модели на одном экземпляре

Аналогичный эксперимент был проведен для 30 экземпляров в целях определения корректности моделирования условных операторов и вероятности исхода события «Отказ». По результатам эксперимента (рис. 2.8) стипендия была предоставлена 12 студентам, в то время как уведомления об отказе получили 18 студентов. Данное распределение в целом соответствует реальным значениям, полученным эмпирическим путем для проверки модели.

Рисунок 2.8 - Проверка модели на 30 экземплярах

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

Рисунок 2.9 - Затраты на проведение процесса

Как видно из таблицы, суммарные затраты на ресурсы составили 63400 рублей, в то же время постоянные издержки на электроэнергию и интернет составили всего 1790 рублей. Таким образом, при дальнейшем анализе не будут рассматриваться варианты оптимизации издержек за коммунальные платежи. Суммарно на процесс было потрачено 65190 рублей, что дает значение в 2173 рубля в среднем на одного студента, что является относительно небольшой суммой для процесса такого масштаба. Необходимо отметить, что несмотря на то, что сотрудник учебного офиса использовался в 70 процентах операций, затраты на оплату его работы составили 6400 рублей, в то время как суммарные затраты на общеуниверситетскую комиссию составили 42000 рублей. Одной из причин данного результата является тот факт, что общеуниверситетская комиссия работает в Москве, где заработная плата выше. Таким образом, одним из вариантов оптимизации издержек будет частичное делегирование обязанностей общеуниверситетской комиссии в региональные филиалы.

Теперь необходимо рассмотреть время выполнение процесса. Общее время на выполнение процесса составило 50 дней 2 часа и 5 минут, таким образом среднее время выполнения одного экземпляра составило 1 день 15 часов и 40 минут. Тем не менее, наиболее быстрый экземпляр завершил работу за 16 часов и 15 минут. Можно наблюдать разницу между средним и наиболее быстрым значением в более чем два раза. Данные факт предполагает, что не хватает ресурсов для их выполнения. Для проверки данной гипотезы был проведен эксперимент с 10 входящими экземплярами. В данном эксперименте общее время составило 8 дней и 9 часов, а среднее значение 19 часов и 48 минут. Таким образом, гипотеза о недостаточности ресурсов подтвердилась и необходимо определить, какие операции являются «проблемными».

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

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

2.3.3. Создание усовершенствованной модели

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

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

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

3. Передача операции «Составление списка кандидатов» учебному офису для сокращения издержек.

4. Перемещение группы операций студенческого совета для параллельного выполнения с операциями учебного офиса.

5. Удаление операция «Созыв комиссии», так как члены комиссии смогут выносить вердикт внутри системы, независимо друг от друга.

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

2.3.4. Проведение экспериментов с усовершенствованной моделью

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

Таблица 2.5 - Проверка усовершенствованной модели с одним экземпляром

Операция	Тип операции	Экземпляров запущено, штук	Экземпляров завершено, штук	Минимальное время, мин.	Максимальное время, мин.	Среднее время, мин.
Стипендия предоставлена	End event	1	-	-	-	-
Изучить положения по предоставлению ПГАС	Task	1	1	30	30	30
Составить пакет документов	Task	1	1	120	120	120
Отправить документы в LMS	Task	1	1	20	20	20
Отказ	End event	0	-	-	-	-

Аналогичный эксперимент был проведен для 30 экземпляров в целях определения корректности моделирования условных операторов и вероятности исхода события «Отказ». По результатам эксперимента (рис. 2.10) стипендия была предоставлена 9 студентам, в то время как уведомления об отказе получил 21 студент. Данное распределение в целом соответствует реальным значениям, полученным эмпирическим путем для проверки модели.

Рисунок 2.10 - Проверка усовершенствованной модели на 30 экземплярах

Для оценки качества усовершенствованной модели необходимо оценить затраты на проведения бизнес-процесса при 30 экземплярах в точке входа (рис. 2.11).



Рисунок 2.11 - Затраты при 30 экземплярах

Как видно из таблицы, суммарные затраты на ресурсы составили 60600 рублей, в то же время постоянные издержки на электроэнергию и интернет составили всего 1800 рублей. Суммарно на процесс было потрачено 62400 рублей, что дает значение в 2080 рублей в среднем на одного студента, что является относительно небольшой суммой для процесса такого масштаба. Так как затраты на одного студента в первой модели составили 2173 рубля, то новая модель экономит 5 процентов затрат. Несмотря на то, что для одного студента данное значение является несущественным в разрезе всего университета экономия является вполне ощутимой и способной компенсировать затраты на разработку автоматизированной системы управления бизнес-процессом в краткосрочной перспективе.

Теперь необходимо рассмотреть время выполнение процесса. Общее время на выполнение процесса составило 31 день 10 часов и 38 минут, таким образом среднее время выполнения одного экземпляра составило 1 день 12 часов и 24 минут. Тем не менее, наиболее быстрый экземпляр завершил работу за 1 день и 5 минут. Таким образом в усовершенствованной модели меньше среднее значения времени выполнения процесса, но больше минимальное. Для проверки данной гипотезы был проведен эксперимент с 10 входящими экземплярами. В данном эксперименте общее время составило 3 дня и 9 часов, а среднее значение 15 часов и 4 минут.

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

Рисунок 2.12 - Среднее время ожидания в усовершенствованной модели

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

- Уменьшено значение средних затрат на одного студента;

- Среднее время выполнения процесса уменьшилось;

- Нет ни одной операции, со средним временем ожидания выше 400 минут.

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

Таблица 2.6 - Сравнение двух моделей

Критерий	Первая модель	Вторая модель	Изменение, %
Сотрудники УО	1	3	200
Количество операций	23	21	8,7
Среднее время выполнения, мин.	2380	2184	-8,2
Минимальное время выполнения, мин.	975	1440	47,6
Средние затраты, руб.	2173	2080	-4,3
Среднее время ожидания операции, мин.	117,6	95,2	-19

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



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

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

3.1 Анализ возможностей системы «Runa WFE»

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

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

- Графическая среда разработки моделей бизнес-процессов «Developer Studio», реализующая моделирование в нотации BPMN;

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

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

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

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

Разработчик системы управления проводит проектирование в двух взаимосвязанных средах: «RunaWFE Free Developer Studio» и «RunaWFE Free Simulation Web Interface». В первой среде происходит разработка модели бизнес-процесса, включающая в себя следующие аспекты: проектирование схемы бизнес-процесса, разработка бот-станций, разработка хранилищ внешних данных, описание переменных и ролей бизнес-процесса, разработка пользовательский и автоматических операций. После завершения разработки модели проводится ее загрузка на локальный сервер. Общий вид окна разработчика в среде «RunaWFE Free Developer Studio» представлен в приложениях (см. прил. В, рис. В3). Основная задача, стоящая перед разработчиком на данном этапе - это проектирование модели системы. В системе существует редактор форм ввода и вывода данных, предназначенный для организации заданий исполнителям. Также одним из основных инструментов разработчика являются задачи сценария, где разработчик может настраивать ход процесса, изменять переменные, формировать документы и прочее (рис. 3.1).

Рисунок 3.1 - Окно выбора типа задачи сценария

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

Рисунок 3.2 - Создание роли с помощью исполнителя на сервере

Администратор сервера создает исполнителей и группы пользователей, определяет их права доступа и отношения в среде «RunaWFE Free Simulation Web Interface» (см. прил. В, рис. В4). Также администратор может запускать бизнес-процессы и назначать доступ для запуска, изменения и отслеживания загруженных процессов. Помимо этого, администратор может вмешиваться в работу бизнес-процесса, проводить его отладку, переназначать исполнителей, просматривать существующие файлы. Основной задачей администратора является поддержание корректной работы как конкретного бизнес-процесса, так и всей компании в целом.

3.2 Разработка модели бизнес-процесса в среде «RunaWFE Free Developer Studio»

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

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

- Подпроцесс «Рассмотрение заявки в кампусе» инициализируется студентом при его решение подать заявку на ПГАС. Процесс может неоднократно запускать до конца сроков подачи заявок на стипендию.

- Подпроцесс «Рассмотрения списка» реализуется общеуниверситетской стипендиальной комиссией и заканчивается подписанием приказа о назначении ПГАС. Процесс начинается с отправления сотрудником учебного офиса кампуса сформированного списка претендентов на получение ПГАС.

3.2 1Разработка подпроцесса «Рассмотрение заявки в кампусе»

Построение модели бизнес-процесса начинается с инициализации ролей (рис. 3.3.), так как процесс будет запускать каждый студент по отдельности, то роль «Студент» будет впоследствии соединена с группой исполнителей «Студенты» с локального сервера. Таким образом, каждый из исполнителей этой группы сможет запускать бизнес-процесс. Аналогично была инициализирована роль «Член студ совета», в то время как роли «Член комиссии 1», «Член комиссии 2», «Член комиссии 3», «Председатель комиссии» и «Сотрудник УО» были привязаны уникально к каждому исполнителю. Данное решение обуславливается тем, что служебные роли сотрудников определены уставами и каждый сотрудник имеет права выполнять исключительно свои или делегированные задачи.

Рисунок 3.3 - Создание ролей подпроцесса «Рассмотрение заявки в кампусе»

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

Рисунок 3.4 - Создание переменных подпроцесса «Рассмотрение заявки в кампусе»

После создания ролей и переменных процесса необходимо было добавить файлы внешних данных, через которые происходит глобальное взаимодействие процесса (рис. 3.5). В данном подпроцессе таким файлом является «СтудентыПермь», в который сохраняются данные о студентах, заявки на стипендиальное обеспечение которых были одобрены. Данный файл автоматически дополняется и в конце сроков проведения конкурса на ПГАС сотрудник учебного офиса отправляет его в общеуниверситетскую стипендиальную комиссию.

Рисунок 3.5 - Добавление источника данных «СписокСтудентов»

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

Рассмотрим фрагмент модели (рис. 3.6) подпроцесса, чтобы показать некоторые используемые методы и операции.

Рисунок 3.6 - Фрагмент модели подпроцесса

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

Рисунок 3.7 - Форма для ввода студентом заявления

После этого система получает информацию о текущей дате с помощью функции «current_date()», затем с сервера автоматически считывается телефон и электронная почта студента, данные записываются в соответствующие переменные (рис. 3.8). Также ФИО студента преобразуются в родительный падеж для последующей генерации заявления с помощью функции «FIO_case_ru('ФИО студента', 2 , "F I O")».

Рисунок 3.8 - Получение информации об электронный почте студента

После того, как все необходимые переменные были получены был создан шаблон для автоматической генерации заявления студента (рис. 3.9). Данному документу дается название «Заявление.docx» и он сохраняется в файловую переменную «Заявление».

Рисунок 3.9 - Фрагмент шаблона для генерации заявления студента

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

Рисунок 3.10 - Форма для проверки документов студента сотрудником УО

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

Рисунок 3.11 - Логическая развилка

Также в ходе процессе происходит взаимодействие со следующими файлами (табл. 3.1). Шаблоны для протоколов заседаний были созданы в соответствии с реальными документами (рис. 3.12).

Таблица 3.1 - Файлы, использующиеся в подпроцессе «Рассмотрение заявки в кампусе»

Название файла	Тип	Способ формирования	Назначение
Документы студента	docx	Загружается пользователем	Необходим для загрузки документов студента
Заявление	docx	Автоматически формируется на основе шаблона	Сформированной заявление студента на предоставление ПГАС
Протокол студ совета	docx	Автоматически формируется на основе шаблона	Протокол заседания студенческого совета
Протокол заседания	docx	Автоматически формируется на основе шаблона	Протокол заседания стипендиальной комиссии
Успеваемость	xlsx	Загружается пользователем	Данные об успеваемости студентов
СтудентыПермь	xlsx	Внешний источник данных	Автоматически заполняется

Рисунок 3.12 - Шаблон для формирования протокола заседания стипендиальной комиссии

В результате выполнения подпроцесса происходит автоматическое заполнение внешнего источника данных (рис. 3.13). Также такие документы, как «Протокол заседания стипендиальной комиссии», «Протокол заседания студенческого совета» и «Заявление студента» автоматически выгружаются для последующего отправления в архив.

Рисунок 3.13 - Реализация выгрузки данных

3.2.2 Разработка подпроцесса «Рассмотрение заявок»

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

Рисунок 3.14 - Роли подпроцесса «Рассмотрение заявок»

Также для моделирования процесса были созданы переменные, с помощью которых будут выполняться операции (рис. 3.15). Основными переменными являются «Список студентов», в которой хранятся данные о студентах, а также «Приказ», которая хранит в себе итоговый приказ о назначении ПГАС.

Рисунок 3.15 - Переменные подпроцесса «Рассмотрение заявок»

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

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

Рисунок 3.16 - Бот работы с внешним хранилищем

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

Рисунок 3.17 - Шаблон протокола заседания комиссии

3.3 Настройка локального сервера в среде «RunaWFE Free Simulation Web Interface»

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

Таблица 3.2 - Группы исполнителей

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

Следующим этапом в разработке системы управления стало проектирование списка исполнителей, входящих в вышеописанные группы и соответствующих бизнес-функциям процессов (табл. 3.3).

Таблица 3.3 - Список исполнителей

Имя пользователя	Полное имя	Группы	Участие в процессе	Роль
motvec	Парыгин Матвей Романович	Студенты	«Рассмотрение заявки в кампусе»	Студент
student1	Иннокентий Петрович Акафьев	Студенты, студенческий совет	«Рассмотрение заявки в кампусе»	Студент, член студ. совета
student2	Аркадий Иванович Долговязов	Студенты, студенческий совет	«Рассмотрение заявки в кампусе»	Студент, член студ. совета
student3	Дмитрий Федорович Карамазов	Студенты	«Рассмотрение заявки в кампусе»	Студент
Александр	Александр Александров	Стипендиальная комиссия	«Рассмотрение заявки в кампусе»	Член комиссии 1
Алексей	Алексей Алексеев	Стипендиальная комиссия	«Рассмотрение заявки в кампусе»	Член комиссии 2
Имя пользователя	Полное имя	Группы	Участие в процессе	Роль
Андрей	Андрей Андреевич Андреев	Стипендиальная комиссия	«Рассмотрение заявки в кампусе»	Председатель комиссии
Афанасий	Афанасий Афанасьев	Стипендиальная комиссия	«Рассмотрение заявки в кампусе»	Член комиссии 3
Виктор	Виктор Викторович Викторов	Общеуниверситетская стипендиальная комиссия	«Рассмотрение заявок»	Член университетской комиссии 1
Виталий	Виталий Витальевич Витальев	Общеуниверситетская стипендиальная комиссия	«Рассмотрение заявок»	Член университетской комиссии 2
Владислав	Владислав Владиславович Владиславов	Общеуниверситетская стипендиальная комиссия	«Рассмотрение заявок»	Член университетской комиссии 3
Вадим	Вадим Вадимович Вадимов	Общеуниверситетская стипендиальная комиссия	«Рассмотрение заявок»	Председатель университетской комиссии
Игорь	Игорь Игоревич Игорев	Учебный офис	«Рассмотрение заявки в кампусе»	Сотрудник УО
Борис	Борис Борисович Борисов	Администрация университета	«Рассмотрение заявок»	Сотрудник администрации
Богдан	Богдан Богданович Богданов	Администрация университета	«Рассмотрение заявок»	Проректор

После завершения данного этапа работы необходимо зайти на сервер под администратором и реализовать полученные таблицы. В первую очередь были созданы группы исполнителей (рис. 3.18).

Рисунок 3.18 - Создание группы студенты

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

Рисунок 3.19 - Карточка исполнителя

Рисунок 3.20 - Группы исполнителей

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

Рисунок 3.21 - Настройка полномочий на запуск процесса

3.4 Проведение экспериментов с системой

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

Рисунок 3.22 - Вход в систему за студента

Во вкладе «Запустить процесс» появляется возможный, в соответствие с моделью, процесс для запуска «Рассмотрение заявки в кампусе» (рис. 3.23).

Рисунок 3.23 - Запуск процесса

После запуска процесса во вкладе задания появляется задание «Подать заявление» при переходе в которое появляется форма ввода для подачи заявления. Заполним форму ввода данными и прикрепим файл, подтверждающий основания для получения ПГАС (рис.3.24).

Рисунок 3.24 - Подача заявление студентом

Теперь необходимо зайти в систему под сотрудником учебного офиса - Игорем Игоревичем Игоревым. Во вкладе задания появилось новое задание «Рассмотреть заявление» перейдя в которое появляется форма для проверки заявления (рис. 3.25).

Рисунок 3.25 - Рассмотреть заявление

Можно заметить, что в форме есть автоматически сформированный файл заявления, открыв который можно посмотреть заявление студента (прил. Д, рис. Д1). Загрузим сюда файл с данными об успеваемости, подтвердим корректность заявления, запрос на консультацию у студенческого совета пока что отправлять не будем. Необходимо отметить, что без загрузки файл об успеваемости выполнить задачу невозможно, так как он является обязательным. Заявление студента автоматически сохраняется на компьютер в случае его одобрения. Теперь необходимо зайти в систему под каждым из трех членов стипендиальной комиссии. Зайдя в систему под Александром Александровичем Александровым, мы получаем следующую форму задания (рис. 3.26).

Рисунок 3.26 - Рассмотрение заявления членом комиссии

Допустим, заявление будет одобрено, сделаем аналогичные действия за остальных членов комиссии. Для опубликования окончательного вердикта необходимо зайти в систему за председателя стипендиальной комиссии Андрея Андреевича Андреева. В форме его задания (рис. 3.27) просмотрим документы и вынесем вердикт - «Одобрено».

Рисунок 3.27 - Просмотр результатов заседания

На данном этапе, в случае положительного решения на заявление, данные о студенте автоматические заполняются в файл (рис. 3.28), а протокол заседания стипендиальной комиссии (прил. Д2, рис. Д2) выгружается на персональный компьютер.

Рисунок 3.28 - Внешний источник данных

Для завершения процесса зайдем в систему под именем студента, подавшего заявления и ознакомимся с протоколом заседания комиссии (рис. 3.29).

Рисунок 3.29 - Просмотр протокола заседания

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

Таблица 3.4 - Переменные, использованные в ходе процесса

Имя	Тип	Значение
ФИО студента	Строка	Парыгин Матвей Романович
Специальность	Строка	Бизнес-Информатика
Курс	Целое число	3
Почта	Строка	test@umail.ru
Телефон	Строка	89761247432
Документы студента	Файл	Диплом учатника.docx
Текущая дата	Дата	16.05.2020
ФИО студента родит	Строка	Парыгина Матвея Романовича
Заявление	Файл	Заявление.docx
ФИО Ректора	Строка	И.О. Фамилия
Комментарий	Текст	Участие в соревнованиях по баскетболу
ЗявкаСтудента	Заявка	id 1 ФИО Парыгин Матвей Романович Курс 3 Образовательная программа Бизнес-Информатика Вид деятельности Спорт
ВердиктСотрудника	Флаг	true
КомментарийСотрудника	Текст	Комментариев нет
РешениеЧленаКомиссии11	Строка	Одобрено
РешениеЧленаКомиссии12	Строка	Одобрено
РешениеЧленаКомиссии13	Строка	Одобрено
Решение председателя	Строка	Одобрено
ФИО члена комиссии 1	Строка	Александр Александров
ФИО члена комиссии 2	Строка	Алексей Алексеев
ФИО члена комиссии 3	Строка	Афанасьев Афанасий
ФИО председателя	Строка	Андрей Андреевич Андреев
Консультация	Флаг	false
Протокол заседания	Файл	ПротоколЗаседания.docx
Одобрено	Строка	Одобрено
Успеваемость	Файл	Успеваемость.xlsx

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

Рисунок 3.30 - Отказ в составлении заявления

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

Рисунок 3.31 - Получение разъяснений студенческого совета

Теперь при входе в систему от лица участника стипендиальной комиссии (рис. 3.32) появляется протокол студенческого совета (прил. Д, рис. Д3). Выполним действия, аналогичные предыдущему примеру.

Рисунок 3.32 - Рассмотрение членом комиссии

В задании председателя стипендиальной комиссии оформим отказ на предоставление ПГАС (рис. 3.33). В этом случае данные о студенте не будут занесены во внешнее хранилище данных, протокол с результатами заседания комиссии придет студенту для оперативного ознакомления с отказом (рис. 3.34).

Рисунок 3.33 - Отказ от предоставления ПГАС

Рисунок 3.34 - Фрагмент протокола заседания стипендиальной комиссии

Зайдем в систему под администратором и проверим граф процесса (прил. Г, рис. Г3). Как видно из графа, все необходимые для проверки ветки были пройдены. Таким образом, можно сделать вывод, что модель процесса корректная и ошибок в ходе работы не возникает.

Теперь необходимо проверить корректность работы подпроцесса «Рассмотрение заявок». Загружаем процесс на сервер, заходим в систему за сотрудника учебного офиса и запускаем процесс. Теперь у сотрудника учебного офиса появилось новое задание - загрузить документы студентов (рис. 3.35).

Рисунок 3.35 - Загрузка архива документов

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

Рисунок 3.36 - Первый этап проверки заявок

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

Рисунок 3.37 - Список одобренных заявок

Одновременно проректору приходит задание (рис. 3.38) в котором содержится проект приказа (прил. Д, рис. Д4), список студентов и возможность подтверждения корректности приказа. В случае его подтверждения приказ сохраняется на компьютер, а процесс завершается.



Рисунок 3.38 - Подтверждение приказа о назначении ПГАС

Выполним вход систему под администратором проверим ход процесса по диаграмме (прил. Г, рис. Г5). Как видно из графа, все операции процесса были успешно выполнены и процесс завершился в точке окончания.



Заключение

В процессе разработки системы управления бизнес-процесса предоставления стипендиального обеспечения и других форм материальной поддержки студентам была описаны архитектура предприятия в нотации Archimate 3.0, создана исполнимая BPMN модель, в ходе экспериментов с который были выявлены недостатки существующей модели и предложена улучшенная модель. Полученная в итоге улучшенная модель оптимизирует бизнес-процесс предоставления ПГАС и прошла проверку на аналогичных экспериментах. На основе улучшенной модели был разработан процесс подачи и проверки заявок на получение ПГАС в системе «Runa WFE». Разработанная система управления успешно прошла все проведенные эксперименты

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

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

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

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

4. Проведен анализ бизнес-процесса, выделены его ключевые показатели.

5. Спроектирована архитектура предприятия.

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

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

8. Реализована система управления бизнес-процессом.

9. Проведены эксперименты на системе управления.

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



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

1. Гриценко Ю.Б. Архитектура предприятия: учеб. пособие / Ю.Б. Гриценко. -- Томск: Томск. гос. ун-та систем управления и радиоэлектроники, 2011. -- 264 с.

2. European Association of Business Process Management [Электронный ресурс] - URL: http://www.eabpm.org/ (дата обращения: 04.03.2020)

3. Скородумов, П. В. Моделирование бизнес-процессов: подходы, методы и средства / П. В. Скородумов // Вопросы территориального развития. - 2014.

4. Фёдоров, И. Г. Моделирование бизнес-процессов в нотации BPMN 2.0: Монография. - 2013.

5. Захман Дж.А. «Структура архитектуры информационных систем». IBM Systems Journal, том 26, номер 3, 1987 г.

6. Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF [Электронный ресурс] URL://http://www.intuit.ru/studies/courses/995/152/lecture/4236?page=2 (дата обращения: 06.05.2020)

7. Archimate Modelling [Электронный ресурс] URL:https://www.archimatetool.com/

8. Методология функционального моделирования IDEF0. Москва: Госстандарт России, 2000.

9. United Modelling Language [Электронный ресурс] - URL: https://www.uml.org/ (дата обращения: 08.05.2020)

10. Каменнова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. Методология ARIS. МетаТехнология, 2001. 327 с.

11. Методология ArchiMate 3.0 [Электронный ресурс] - URL: http://koptelov.info/archimate_3_0/ (дата обращения: 08.03.2020)

12. Pega [Электронный ресурс] - URL: https://www.pega.com/ (дата обращения: 12.04.2020)

13. Terrasoft [Электронный ресурс] - URL: https://www.terrasoft.ua/ (дата обращения: 12.04.2020)

14. Pipefy [Электронный ресурс] - URL: https://www.pipefy.com/ (дата обращения: 13.04.2020)

15. RunaWFE Free [Электронный ресурс] - URL: https://www.runawfe.org/ (дата обращения: 13.04.2020)

16. Bizagi Studio [Электронный ресурс] - URL: https://www.bizagi.com/en/platform/studio (дата обращения: 13.04.2020)



Приложение А. Архитектурные точки зрения

Рисунок А1 - Точка зрения информационной структуры



Рисунок А2 - Точка зрения взаимодействия бизнес-процессов

Рисунок А3 - Организационная точка зрения



Приложение Б. Модели бизнес-процесса в Bizagi Modeler

Рисунок Б1 - Модель бизнес-процесса предоставления ПГАС «Как есть»

Рисунок Б2 - Улучшенная модель

Рисунок Б3 - Среднее время ожидания при выполнении операций



Приложение В. Дополнительные материалы

Рисунок В1 - Модель Захмана [1]

Рисунок В2 - Инструментарий ArchiMate 3.0. [11]

Рисунок В3 - Интерфейс «RunaWFE Free Developer Studio»

Рисунок В4 - Веб-интерфейс администратора сервера



Приложение Г. Модели бизнес-процесса в «Runa WFE»

Рисунок Г1 - Модель подпроцесса «Рассмотрение заявки в кампусе»

Рисунок Г2 - Схема завершенного процесса «Рассмотрение заявки в кампусе» первый эксперимент

Рисунок Г3 - Схема завершенного процесса «Рассмотрение заявки в кампусе» второй эксперимент

Рисунок Г4 - Модель подпроцесса «Рассмотрение заявок»

Рисунок Г5 - Схема завершенного процесса «Рассмотрение заявок»



Приложение Д. Сформированные документы

Рисунок Д1 - Заявление студента

Рисунок Д2 - Протокол заседания стипендиальной комиссии

Рисунок Д3 - Протокол студенческого совета

Рисунок Д4 - Протокол заседания общеуниверситетской комиссии

Рисунок Д5 - Приказ о назначении ПГАС



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

Пермский филиал федерального государственного автономного

образовательного учреждения высшего образования

«Национальный исследовательский университет

«Высшая школа экономики»

УТВЕРЖДАЮ	УТВЕРЖДАЮ
Руководитель: к.т.н., доцент, доцент кафедры информационных технологий в бизнесе	Директор филиала: НИУ ВШЭ в Перми
_________________ / А.И. Дерябин/ «___»________ 2020 г.	__________Г.Е. Володина «___»________ 2020 г.

Руководство пользователя к системе управления бизнес-процесса по предоставлению Повышенной Государственной Академической Стипендии

Тема: «Стипендиальное обеспечение»

НИУ ВШЭ-БИ-16-2

Пермь, 2020



Аннотация

Настоящий документ является руководством пользователя по системе управления бизнес-процессом предоставления стипендиального обеспечения студентам в форме ПГАС.

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

1. Введение.

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

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

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

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

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

Е.1. Введение

Е.1.1. Область применения программы

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

Е.1.2. Возможности программы

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

Е.1.3 Требуемый уровень знаний

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

1. Использование веб-браузера.

2. Базовые принципы работы с файлами.

3. Настройка интернет-подключения.

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

Система управления бизнес-процессами «Предоставление ПГАС» предназначена для подачи заявлений на ПГАС, рассмотрения заявлений и составлении приказов о назначении и протоколов заседаний.

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

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

Е.3. Подготовка к работе

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

Для работы с системой управления бизнес-процессами «Предоставление ПГАС» требуется следующее программное обеспечение:

1. Веб-браузер.

2. Офисные приложение Microsoft Excel и Microsoft Word (для импорта приказа и протоколов).

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

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

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

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

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

Е.4. Описание операций

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



Таблица Е.4.1 Выполняемые функции и задачи

Функции	Задачи	Описание
Ввод данных для заявления	Сохранение введенных студентов данных в локальные переменные	Пользователю открывается форма для ввода данных
Формирование заявление	Корректность заявления и заполнение его реальными данными	Функция реализуется автоматически
Проверка заявлений	Возможность проверки введенных студентом данных на корректность	Пользователям открываются формы, в которых выводятся данные
Составление протоколов заседаний	Составление корректного протокола заседания стипендиальной комиссии	Функция реализуется автоматически

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

Задача: «Ввод данных для составления заявления».

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

1. Открыта веб-страница системы.

Подготовительные действия:

1. Студент запустил процесс подачи заявки.

2. Студент подготовил необходимые документы

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

1. Открыть форму для выполнения задания.

2. Заполнить требуемые в форме поля.

Заключительные действия:

1. Нажать кнопку «задания исполнено» для завершения операции.

Задача: «Проверка заявления».

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

1. Открыта веб-страница системы.

Подготовительные действия:

1. Студент загрузил данные.

2. Открыта форма задания.

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

1. Проверить документы студента.

2. Выбрать соответствующие решению действия.

Заключительные действия:

1. Нажать кнопку «задания исполнено» для завершения операции.

Задача: «Проверка приказа о назначении ПГАС».

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

1. Открыта веб-страница системы.

Подготовительные действия:

1. Стипендиальная комиссия провела заседание, сформирован протокол.

2. Открыта форма задания.

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

1. Ознакомиться с проектом приказа.

2. Вынести заключительный вердикт.

Заключительные действия:

1. Нажать кнопку «задания исполнено» для завершения операции.

Задача: «Отправка списка»

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

1. Завершился срок подачи заявок.

2. Открыта веб-страница системы.

Подготовительные действия:

1. Пользователь открыл форму задания.

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

1. Загрузить архив с документами студента.

2. Завершить задание.

Заключительные действия:

1. Нажать кнопку «задания исполнено» для завершения операции.

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

Таблица Е.5.1 Аварийные ситуации

Класс ошибки	Ошибка	Описание ошибки	Требуемые действия пользователя при возникновении ошибки
Ошибка при работе с информацией	Некорректные данные ввода	Пользователь ввел данные, не соответствующие правилам ввода	Продолжить работу в программе после сообщения об ошибке
Ошибка при работе с файлами	Файл не сохранен	Изменена структура сервера	Обратиться к администратору сервера

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

Рекомендаций к освоению система управления бизнес-процессами «Предоставление ПГАС» не требует.



Приложение Ж. Техническое задание

Пермский филиал федерального государственного автономного

образовательного учреждения высшего образования

«Национальный исследовательский университет

«Высшая школа экономики»

УТВЕРЖДАЮ	УТВЕРЖДАЮ
Руководитель: доцент кафедры информационных технологий в бизнесе	Директор филиала: НИУ ВШЭ в Перми
_________________ /А.И. Дерябин/ «___»________ 2020 г.	__________Г.Е. Володина «___»________ 2020 г.

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

Тема: «Предоставление ПГАС»

НИУ ВШЭ-БИ-16-2

Пермь, 2020



Аннотация

Настоящий документ является техническим заданием по системе управления бизнес-процессом предоставления ПГАС.

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

1. Введение

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

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

4. Требования к программе

5. Требования к программной документации

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

7. Стадии и этапы разработки

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

Ж.1. Введение

Ж.1.1. Наименование программы

Наименование программы: "Система управления бизнес-процесса предоставления ПГАС".

Ж.1.2. Назначение и область применения

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

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

Разработка ведется на основании документа ГОСТ 19.201-78 ЕСПД.

Организация, утвердившая этот документ - Государственный комитет СССР по стандартам от 18 декабря 1978 г. N 3351 дата введения установлена 01.01.80

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

<...